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NATIONAL FOREWORD 

This Indian Standard ( Part 2 ) ( First Revision ) which is identical with IEC 60625-2 ( 1993 ) 'Programmable 
measuring instruments — Interface system ( byte serial, bit parallel ) — Part 2 : Codes, formats, 
protocols and common commands' issued by the International Electrotechnica! Commission ( IEC ) 
was adopted by the Bureau of Indian Standards on the recommendation of Electronic Measuring 
Instruments, Systems and Accessories Sectional Committee and approval of the Electronics and 
Telecommunication Division Council. 

This standard ( Part 2 ) specifies a set of codes, formats and communication protocols for programmable 
measuring instruments. 

This standard was first published in 1983 and was identical to IEC 60625-2 ( 1980 ) 'An interface 
system for programmable measuring instruments ( byte serial, bit parallel ) — Part 2: Code and 
format conventions'. IEC 60625-2 ( 1980 ) has since been revised in 1993. In view of the technological 
advances at the international level, this standard is being revised to align it with the latest international 

practices. 

The text of the IEC has been. approved as suitable for publication as Indian Standard without deviations. 
Certain conventions are, however, not identical to those used in Indian St-ndards. Attention is particularly 
drawn to the following: 

a) Wherever the words 'International Standard' appear referring to this standard, they should be 
read as 'Indian Standard'. 

b) Comma (,) has been used as a decimal marker while in Indian Standards, the current practice 
is to use a point {.) as the decimal marker. 

CROSS REFERENCES 

In the adopted standard, reference appears to certain International Standards for which Indian Standards 
also exist. The corresponding Indian Standards which are to be substituted in their place are listed 
below along with their degree of equivalence for the editions indicated: 



International 
Standard 

IEC 60625-1 ( 1993 ) Programmable 
measuring instruments — Interface 
system ( byte serial, bit parallel ) — 
Part 1 : Functional, electrical and 
mechanical specifications, system 
applications and requirements for 
the designer and user 

ISO/IEC 646 (1991 ) Information 
technology — ISO 7-bit coded 
character set for information 
interchange 

ISO 2955 (1983) Information 
processing — Representation of 
SI and other units in systems with 
limited character sets 



Corresponding 
Indian Standard 

IS 10767 ( Part 1 ) : 2001 Programmable 
measuring instruments — Interface 
system ( byte serial, bit parallel ) — 
Part 1 : Functional, electrical and 
mechanical specifications, system 
applications and requirements for the 
designer and user ( first revision ) 



Degree of 
Equivalence 

Identical 



IS 10315 : 1997 ISO 
character set for 
interchange 



7-bit coded 
information 



IS 11366 : 1985 Representation of SI 
and other units in systems with limited 
character sets for information 
processing 

(i) 



do 



do 
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The concerned Technical Committee responsible for preparation of this standard has reviewed the 
provisions of the following International publications and has decided that they are acceptable for use 
in conjunction with this standard: 

IEC 60559 ( 1989 ) Binary floating-point arithmetic for microprocessor systems 

ISO 6093 ( 1985 ) Information processing — Representation of numerical values in character 
strings for information interchange 

Only the English language text of the International Standard has been retained while adopting it in 
this Indian Standard. 
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PROGRAMMABLE MEASURING 

INSTRUMENTS — INTERFACE SYSTEM 

( BYTE SERIAL, BIT PARALLEL ) 

PART 2 CODES, FORMATS, PROTOCOLS AND COMMON COMMANDS 

( First Revision ) 

SECTION 1 : GENERAL CONCEPTS 



1 General 



1.1 Scope 



This part of IEC 625 specifies a set of codes and formats to be used by devices connected 
via the IEC 625-1 bus. This standard also defines communication protocols necessary to 
effect application independent device-dependent message exchanges and further defines 
common commands and characteristics useful in instrument system applications. 



This standard is intended to directly apply to small to medium -scale instrument systems. It 
applies to systems comprised mainly of measurement, stimulus, and interconnect devices 
with an instrumentation controller, the standard, may also apply to certain devices Outside 
the scope of the instrument system environment. 



As well as defining a variety of device-dependent messages, this standard extends and 
further interprets certain interface functions contained in IEC 625-1 while remaining 
compatible with that standard. 

This standard covers the following topics: 

- Standard IEC 625-1 subsets. 

- Standard message handling protocols including error handling. 

- Unambiguous program and response message syntactic structures. 

- Common commands useful in a wide range of instrument system applications. 

- Standard status reporting structures. 

- System configuration and synchronization protocols. 

Use of this standard does not relieve the user from the burden of responsibility for system 
compatibility at the application level, the user must be familiar with the characteristics of 
all the system components in order to configure an optimum system. 

The intended readers of tWi standard include both controller and device designers. 
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1 .2 Objectives 

The objectives of this standard are: 

1) To provide a well-defined and unambiguous structure of codes, formats, protocols, 
and common commands. 

2) To retain generality to accommodate the needs of a wide variety of applications 
within the scope of the standard. 

3) To promote the degree to which devices from different manufacturers may be 
interconnected and used, without modification. 

4) To enable the interconnection of instrumentation and related devices with both 
limited and extensive capability to generate, process and interpret a variety of different 
message types. 

5) To define codes, formats, protocols, and common commands that will reduce the 
costs of generating application software and the costs of system integration. 

6) To permit direct communication among instrument system devices without 
extraordinary translation and conversion of special codes and formats. 

1.3 Notation 

This standard defines several common English words to have special meaning in the 
context of this standard. These words have different connotations in IEC 625-1 but, for 
readability and conciseness of text, are the preferred words for use in IEC 625-2. To avoid 
confusion, these words always appear In bold type when referenced in this document. 
Words which appear in bold type are: system, device, controller, system bus, and 
system interface. Local messages peculiar to IEC 625-2 will also appear in lower case 
bold type. 



This standard also defines syntactic elements used to describe messages transferred on 
the bus. Syntactic elements are enclosed by angle brackets, e.g. <syntactic element>, to 
set them off from local messages, remote messages, and normal text. 



2 Normative references 

The following normative documents contain provisions which, through reference in this 
text, constitute provisions of this part of IEC 625. At the time of publication, the editions 
indicated were valid. All normative documents are subject to revision, and parties to 
agreements based on this part of IEC 625 are encouraged to investigate the possibility of 
applying the most recent editions of the normative documents indicated below. Members 
of IEC and ISO maintain registers of currently valid International Standards. 



IEC 559: 1 989, Binary floating-point arithmetic for microprocessor systems 

IEC 625-1: 1993. Programmable measuring instruments - Interface system (byte serial, bit 
parallel) - Part 1: Functional, electrical and mechanical specifications, system applications 
and requirements for the designer and user 
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I SO/ 1 EC 646: 1991 , Information technology - ISO 7-bit coded character set for information 
interchange 

ISO 2955: 1983, Information processing - Representation of SI and other units in systems 
with limited character sets 

ISO 6093: 1985, Information processing - Representation of numerical values in character 
strings for information interchange 

3 System considerations 

3.1 Definitions 

The following definitions apply for the purpose of this part of IEC 625. This clause contains 
only general definitions. Detailed definitions are given in further clauses, as appropriate. 
For definitions relating specifically to IEC 625-1 , see 1.3 of that standard. 



system: A group of devices and a controller interconnected with a system Interface. 

device: A component of a system that does not function as the system-controller but 
typically receives program messages from, and sends response messages to, the 
controller. A device may optionally have the capability to receive control from the 
controller and become the controller-in-charge of the system*. A device meets all the 
requirements stated in clause 4 of this standard. 

controller: The compontftt of * system that functions as the system controller. A 
controller typically sends program messages to and receives response messages from 
devices. A controller may pass and receive control per the protocols in this standard. A 
controller meets all the requirements stated in clause 14 of this standard. 



system bus: The IEC 625-1 bus and protocols that interconnect the devices and 
controllers in a system. The content of this standard applies to device-dependent traffic 
over this bus. 

system Interface: An interface which connects a device or controller to the system bus. 



A "non-lEC 625-2 system interface" is any interface other than the system Interface 
which may happen to be connected to a device or controller. 

3.2 System message traffic 

This standard is optimized for a system in which the devices do not become controller-in- 
charge. The usual message traffic is assumed to be from "controller-to-device" or from 
"device-to-controller". 



All IEC 625-2 components, that is. devices and controllers in a system comprise what is defined in 
IEC 625-1 as "device*. 

13 
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The flexibility of the program message syntax (clause 7) also may allow the use of an 
IEC 625-2 component in a system which contains non-lEC 625-2 components. 



In a system with a device and a non-compliant controller, the flexible listening formats 
allow the achievement of a higher degree of compatibility. This compatibility is realized by 
requiring minor variations in syntax to be accepted by the device. These variations are 
designed to be syntaxes that are easy to generate on a variety of controllers. They may 
even be the nbr^compliant controller's default syntax. Such systems are beyond the 
scope of this standard and may not perform their intended functions. 



Controller 



Program messages (clause 7) 



Response messages (clause 8) 




Figure 3-1 -Usual message traffic 

3.2.1 Program and response message relationships 

Subsequent clauses will describe in detail the allowed syntax and semantics tor system 
message traffic The philosophy of this standard is that devices receive in a rr^re flexible 
manner than they send. ■ ■----■.■■■■-;• ^1, 



"S&v? 



Thus, a range of variations of syntax defined by this standard must be accepted when 
devices listen. Likewise, a precise syntax, also identified by this standard, is required 
when devices talk. 

These controller-to-device (program) and device-to-controller (response) messages are 
composed of syntactic elements described in clauses 7 and 8, respectively. 

The following example demonstrates this relationship among program and response 
messages for a device that has a range that may be programmed and queried. The 
device has discrete ranges of 1.2, 12 and 120. 

The following is an example of flexible reception of range programming with the device 
listening. 



Flexible reception example 

Controller sends 

RANGE 12.45 
or RANGE 12 
or RANGE 1.2E+1 



Device interprets: 

RANGE 12 
RANGE 12 
RANGE 12 
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The syntactic rules of clause 7, device listening formats, provide for this flexibility of 
interpretation. 

The following is an example of precise response to range status request with the device 
talking. 

Precise response example 

Controller sends Device sends 

RANGE? 12 

The syntactic rules of clause 8, Device talking formats, ensure the device responds with a, 
precise format. 

3.2.2 Other message traffic 

In addition to controller-to-device and device-to-controller messages, protocols are defined 
to facilitate passing control, clause 17. 

Device-to-device protocols are not explicitly defined in this document. However, message 
traffic between devices shall follow the syntax for <RESPONSE MESSAGES> defined in 
clause 8. 

3.3 Functional layers 

The purpose of an interface system is to support the system application of the user. In the 
schema of which this standard is a part, the system contains successive, independent 
"levels" of communication protocol as shown in figure 3-2. 

Each layer shown has associated common "messages", which form protocols to 
communicate between itself and the corresponding layer in the participating system 
components. 

The protocols are designed for communication between non-peer entities due to the 
requirements of the IEC 625-1 standard. No attempt has been made to associate the 
protocol layering with the ISO model for open systems interconnection. 
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BUS 



Device - Specific messages 



Common commands and queries 



System component x 



Specified 
by device 
designer 



IEC 625-2 



Syntax and data structures 



Remote IF messages 




IEC 625-1 



System component y 



IEC 625-2 



Specified 
by device 
designer 



The layers have the following representations: 
Layer D represents device functions 
Layer C represents common system functions 
Layer B represents message communication functions 
Layer A represents interface functions (IF) 

Where layers 0, C and B contain IEC 625-1 device-dependent messages and layer A contains IEC 625-1 
interface messages. 

Figure 3-2 - IEC 625-1 and IEC 625-2 functional protocol layers 
SECTION 2: DEVICE RELATED SPECIFICATIONS 

4 Device compliance criteria 

A device shall have certain capabilities. This clause lists the capabilities which this 
standard requires in a device. A device may optionally contain additional capabilities. Any 
optional device capabilities which are described by this standard are also listed in this 
section. 

Compliance for a device is divided into several areas which are considered separately. A 
device shall satisfy all the required functionality in each of the areas in order to comply 
with this standard. 
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This clause summarizes requirements which are fully specified in the referenced clause. 
The device designer shall use the requirements stated in later clauses when actually 
designing a device. 

4.1 IEC 625-1 requirements 

A device shall contain these IEC 625-1 subsets listed in table 4-1 and no others. 

Table 4-1 - IEC 625-1 interface requirements for devices 



IEC 625-1 


IEC 625-1 


IEC 625-2 


Interface function 


Subsets 


Subclause 


Source Handshake 


SH1 


5 1.1 


Acceptor Handshake 


AH1 


5.1.2 


Talker 


T5, T6, TE5, or TE6 


5.3 


Listener 


L3, L4, LE3, or LE4 


5.4 


Service Request 


SR1 


5.5 


Remote/Local 


RLOorRU 


5.6 


Parallel Poll 


PPOorPPI 


5.7 


Device Clear 


DC1 


5.8 


Device Trigger 


DTOorDTI 


5.9 


Controller 


CO, or C4 with C5, C7, C9, or C1 1 


5.10 


Electrical Interface 


El or E2 


5.11 



A device shall comply with IEC 625-1. It shall also meet all requirements stated in 
clause 5 of this standard: 

4.2 Message exchange requirements 

A device shall follow all the requirements listed in clause 6 of this standard. 



A device's input buffer may take on several forms. The input buffer's length may be a 
fixed number of bytes. It may contain a fixed number of complete <PROGRAM 
MESSAGES>. Its length in bytes or <PROGRAM MESSAGES> may vary with the device's 
state. See 6.1.5. 

Certain query messages may generate the actual response message when the query is 
received. Other query messages may generate the actual response when the controller 
reads the response. See 6.4.5.4. 

Execution of individual parsable elements may be done as they are received. The device 
may also wait until either a <PROGRAM MESSAGE UNIT SEPARATOR> or a <PROGRAM 
MESSAGE TERMINATOR> is parsed before executing preceding <PROGRAM MESSAGE 
UNIT> elements. A device may contain a mix of these types of commands- See 6.4.5.1. 
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4.3 Syntax requirements 

Clauses 7 and 8 describe a set of functional elements which the device designer uses to 
describe the programming language for a specific device. The entire syntax described in 
clauses 7 and 8 is not required in every device. Some functional elements are required 
and some are optional. 

4.3.1 Required functional elements 

Table 4-2 lists the required functional elements. 

Table 4-2 - Required functional elements for devices 



Device listening functional element 


Subclause 


<PROGRAM MESSAGE> 

<PROGRAM MESSAGE TERMINATOR> 

<PROGRAM MESSAGE UNIT> 

<PROGRAM MESSAGE UNIT SEPARATOR> 

<COMMAND MESSAGE UNIT> 

<QUERY MESSAGE UNIT> 

<COMMAND PROGRAM HEADER>* 

<QUERY PROGRAM HEADER>* 

<PROGRAM HEADER SEPARATOR> 

<PROGRAM DATA SEPARATOR> 

<PROGRAM DATA> 

<DECIMAl NUMERIC PROGRAM DATA> 


7.3.2 

7.5 

7.3.2 

7.4 1 

7.3.2 

7.3.2 

7.6.1 

7.6.2 

7.4.3 

7.4.2 

7.3.2 

7.7.2 


Device talking functional element 


Subclause 


<RESPONSE MESSAGE> 
<RESPONSE MESSAGE TERMINATOR> 
<RESPONSE MESSAGE UNIT> 
<RESPONSE MESSAGE UNIT SEPARATOR> 
<RESPONSE DATA> 
<RESPONSE DATA SEPARATOR> 
<NR1 NUMERIC RESPONSE DATA> 
<ARBITRARY ISO 7-bit RESPONSE DATA> 


8.3.2 

8.5 

8.3.2 

8.4.1 

8.7 

8.4.2 

8.7.2 

8.7.11 


* <compound command program header> and <compound 
query program header> are not required encoding 
elements. 



4.3.2 Optional functional elements 

Table 4-3 lists the optional functional elements. 
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Table 4-3 - Optional functional elements for devices 



Device listening functional element 


Subclause 


<COMMAND PROGRAM HEADERS 
<QUERY PROGRAM HEADER>* 
CHARACTER PROGRAM DATA> 
<SUFFIX PROGRAM DATA> 
<NON-DECtMAL NUMERIC PROGRAM DATA> 
<STRING PROGRAM DATA> 
ARBITRARY BLOCK PROGRAM DATA> 
<EXPRESSION PROGRAM DATA> 


7.6.1 
7.6.2 
7.7.1 
7.7.3 
7.7.4 
7.7.5 
7.7.6 
7.7.7 


Device talking functional element 


Subclause 


<RESPONSE HEADER SEPARATOR 
<RESPONSE HEADER> 
<CHARACTER RESPONSE DATA> 
<NR2 NUMERIC RESPONSE DATA> 
<NR3 NUMERIC RESPONSE DATA> 
<HEXADECIMAL NUMERIC RESPONSE DATA> 
<OCTAL NUMERIC RESPONSE DATA> 
<BINARY NUMERIC RESPONSE DATA> 
<STRING RESPONSE DATA> 
<DEFINITE LENGTH ARBITRARY BLOCK 
RESPONSE DATA> 

<INDERNITE LENGTH ARBITRARY BLOCK 
RESPONSE DATA> 


8.4.3 

8.6 

8.7.1 

8.7.3 

8.7.4 

8.7.5 

8.7.6 

8.7.7 

8.7.8 

8.7.9 

8.7.10 


* <com pound command program header> and 
< com pound query program header> are optional encoding 
elements though other encoding elements are required. 



4.4 Status reporting requirements 

4.4. 1 Required status reporting capability 

A device shall follow the status reporting model presented in clause 1 1 . The device shall 
include those commands related to status reporting described in clause 10 and listed in 
table 4-4. 

Table 4-4 - Required status reporting common commands 



Status reporting 


Command 


Subclause 


*CLS 


10.3 


*ESE 


10.10 


*ESE? 


10.11 


*ESR? 


10.12 


*SRE 


10.34 


*SRE? 


10.35 


*STB? 


10.36 
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A device shall implement the status byte register, the Service Request Enable Register, 
the Standard Event Status Register, and the Standard Event Status Enable Register 
illustrated in figure 4-1 . 




Service 

•Request 

Generation 



SRE <NRf> *SRE? 



Figure 4-1 - Required status reporting capabilities 
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4.4.2 Optional status reporting capability 



A device may include any number of condition registers, event registers, enable registers, 
and queues provided they follow the model presented in clause 11. 



The device may optionally include the ability to save enable registers when power is 
cycled. This capability also requires non-volatile memory and all of the commands listed in 
table 4-5. 

Table 4-5 - Optional power-on common commands 



Power-on 


Command 


Subclause 


•PSC 
•PSC? 


10.25 
10.26 



The device may optionally include the ability to respond to a parallel poll. This capability 
also requires the IEC 625-1 subset PP1 and all of the commands listed in table 4-6. 



Table 4-6 - Optional Parallel Poll common commands 



Parallel Poll 


Command 


Subclause 


'1ST? 
'PRE 
'PRE? 


10.15 
10.23 
10.24 



4.5 Common commands 

This standard lists some reserved commands. Some of the commands are required, some 
are optional, and some shall be implemented in groups. 



4.5.1 Required common commands 

The common commands, listed in 4.4.1, related to status reporting and the common 
commands, listed in 4.6, related to synchronization are required. The commands, listed in 
table 4-7, related to internal operations are also required. 



Table 4-7 - Required internal operation common commands 



Internal operations 


Command 


Subclause 


•IDN? 
•RST 
*TST? 


10.14 
10.32 . 
10.38 
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4.5.2 Optional common commands 

In some cases, the implementation of a common command is independent of other 
common commands or device capabilities. In other cases, common commands shall be 
implemented in groups or in conjunction with some other device capability. 



4.5.2.1 Resource description commands 

The resource description commands, listed in table 4-8, are optional and loosely coupled. 
If the resource description can be written into the device (*RDT), then the device shall 
also include the capability to read the resource description (*RDT?). The *RDT? query, 
however, may be included without the *RDT command. 



Table 4-8 - Optional resource description common commands 



Resource description 


Command 


Subclause 


•RDT 
•RDT? 


10.30 
10.31 



4.5.2.2 Protected user data commands 

The protected user data commands, listed in table 4-9, are optional. If any commands in 
this group are implemented, however, then all commands in this group shall be 
implemented. 

Table 4-9 - Optional protected user data commands 



Protected data 


Command 


Subclause 


•PUD 
•PUD? 


10.27 
10.28 



4.5.2.3 Calibration command 

The self-calibration command, listed in table 4-10, is optional. 

Table 4-10 - Optional calibration command 



Calibration 


Command 


Subclause 


•CAL? 


10.2 



4.5.2.4 Trigger command 

The trigger command, listed in table 4-11, is optional. It is required, however, if the device 
has DT1 capability. If the trigger command is implemented the device shall also have DT1 
capability. 
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Table 4-1 1 - Optional trigger command 



Trigger 


Command 


Subclause 


*TRG 


10.37 



4.5.2.5 Trigger macro commands 

The trigger macro commands, listed in table 4-12, are optional. If any commands in this 
group are implemented, however, then all commands in this group shall be implemented 
and the device shall have DT1 capability. 

Table 4-12 - Optional trigger macro commands 



Trigger macro 


Command 


Subclause 


•DDT 
*DDT? 


10.4 
10.5 



If the trigger macro commands are implemented, the device shall also include the 
<ARBITRARY BLOCK PROGRAM DATA> and <DEFINITE LENGTH ARBITRARY BLOCK 
RESPONSE DATA> functional elements. 



4.5.2.6 Macro commands 

The macro commands, listed in table 4-13, are optional. If any commands in this group are 
implemented, however, then all commands in this group shall be implemented. 



Table 4-13 - Optional macro commands 



Macros 


Command 


Subclause 


*DMC 


10.7 


•EMC 


10.8 


*EMC? 


10.9 


•GMC? 


10.13 


*LMC? 


10.16 


•PMC 


10.22 



If the macro commands are implemented, the device shall also include the <STRING 
PROGRAM DATA>, <ARBITRARY BLOCK PROGRAM DATA>, <STRING RESPONSE 
DATA>, and <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> functional 
elements. 
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4.5.2.7 Option identification command 

The option identification command, listed in table 4-14, is optional. 

Table 4-14 - Optional option identification command 



Options 


Command 


Subclause 


•OPT? 


10.20 



4.5.2.8 Stored setting commands 

The stored setting commands, listed in table 4-15, are optional. If any commands in this 
group are implemented, however, then all commands in this group shall be implemented. 



Table 4-15 - Optional stored setting commands 



Stored settings 


Command 


Subclause 


•RCL 
•SAV 


10.29 
10.33 



4.5.2.9 Learn command 

The learn command, listed in table 4-16, is optional. 

Table 4-16 - Optional learn command 



Learn 


Command 


Subclause 


•LRN? 


10.17 



4.6 Synchronization requirements 

Clause 12 describes capability which is required in all devices for synchronization. A 
device designer may choose which operations have pending operation flags associated 
with them, according to the rules in clause 12. 

The required common commands related to synchronization are listed in table 4-17. 



Table 4-17 - Required synchronization commands 



Synchronization 


Command 


Subclause 


*OPC 

•OPC? 

•WAI 


10.18 
10.19 
10.39 
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4.7 System configuration capability 



Clause 13 describes optional capability which is used to configure the IEC 625-1 
addresses of devices. This capability is implemented by including the common commands 
in table 4-18. 

Table 4-18 - Optional system configuration commands 



Auto configure 


Command 


Subclause 


*AAD 
•DLF 


10.1 
10.6 



If either command is implemented then both commands shall be implemented. 



These commands cause the device temporarily to suspend normal message exchange 
protocols and to use different protocols. To ensure compatibility with other devices, the 
device designer must carefully adhere to these different protocols. 



4.8 Controller capability 

4.8.1 Required controller capability 

A device is not required to have any controller capability. 

4.8.2 Optional controller capability 

If a device has any controller capability, it shall include the IEC 625-1 C4 subset, the pass 
control back command listed in table 4-19, and it shall obey the passing control protocol 
described in 17.4, and it shall obey the requesting control protocol described in 17.5. 

Table 4-19 - Optional passing control command 



Passing control 


Command 


Subclause 


•PCB 


10.21 



4.9 Device documentation requirements 

All devices shall supply information to the user about how the device has implemented 
this standard. This information shall include: 

1) A list of IEC 625-1 interface functions subsets implemented, clause 5. 

2) A description of device behaviour when the address is set outside the range 0-30, 
see 5.2. 

3) A description of when a user-initiated address change is recognized by the device. 
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4) A description of the device setting at power-on, see 5.12. Any commands which 
modify the power-on settings shall also be included. 

5) A description of message exchange options: 

a) the size and behaviour of the Input Buffer, see 6.1.5; 

b) which queries return more than one <RESPONSE MESSAGE UNIT>, see 6.4.3; 

c) which queries generate a response when parsed, see 6.4.5.4; 

d) which queries generate a response when read, see 6.4.5.4; 

e) which commands are coupled, see 6.4.5.3. 

6) A list of functional elements used in constructing the device-specific commands. 
Whether <compound command program header> elements are used must also be 
included, see 7.1.1 and 7.3.3. 

7) A description of any buffer size limitations related to block data, see 7.7.6.5. 

8) A list of the <PROGRAM DATA> elements which may appear within an 
<expression> as well as the maximum sub-expression nesting depth. Any 
additional syntax restrictions which the device may place on the <expression> 
shall also be included. 

9) A description of the response syntax for every query, see 8. 

10) A description of any device-to-device message transfer traffic which does not follow 
the rules for <RESPONSE MESSAGE> elements, see 8.1. 

11) The size of any block data responses, see 8.7.9.4. 

12) A list of common commands and queries which are implemented, see 10. 

13) A description of the state of the device after successful completion of the 
calibration query, see 10.2. 

14) The maximum length of the block used to define the trigger macro, if *DDT is 
implemented, see 10.4. 

15) The maximum length of macro labels, the maximum length of the block used to 
define a macro, and how recursion is handled during macro expansion, if the macro 
commands are implemented, see 10.7. 

16) A description of the response to the identification common query, *IDN?, 
see 10.14. 

17) The size of the protected user data storage area, *PUD, see 10.27. 

18) The size of the resource description, if the *RDT command or *RDT? query are 
implemented, see 10.30 and 10,31. 

19) A description of the states affected by *RST, (10.32), "LRN?, (10.17), *RCL, 
(10.29), and *SAV, (10.33). 

20) A description of the scope of the self-test performed by the *TST? query, 
see 10.38. 



26 



IS10767(Part2):2001 
IEC 60625-2 (1993) 

21) A description of additional status data structures used in the device's status 
reporting, see 1 1 . 

22) For each command, a statement describing whether it is overlapped or sequential. 

23) For each command the device documentation shall specify the functional criteria 
that are met when an operation complete message is generated in response to that 
command, see 12.8.3. 

5 Device Interface function requirements 

This clause describes the IEC 625-1 interface function requirements of a device. It 
specifies the additional requirements of a device that are directly associated with the ten 
IEC 625-1 interface functions. These requirements are intended to supplement the 
IEC 625-1 specification for the IEC 625-2 system environment as described in this 
standard. 

5.1 Handshake requirements 

5.1.1 Source handshake requirements 

A device shall contain the SH1 (complete capability) subset. It shall make the transition 
from Source Delay State (SDYS) to Source Transfer State (STRS) only if the ready for 
data (RFD) message is TRUE and the data accepted (DAC) message is FALSE, see 6.5.3. 



5.1 .2 Acceptor handshake requirements 

A device shall contain the AH1 (complete capability) subset and shall additionally follow 
the requirement of the following paragraph. 

A device shall enter AIDS (Acceptor Idle State) of the AH function within one millisecond 
after ATN assumes the FALSE state if the device was in LIDS (Listener Idle State) when 
ATIM was TRUE. This requirement ensures that the device will operate reliably with the 
Find Listeners common controller protocol, see 17.6. 



5.2 Address requirements 

A device shall have the same talk and listen addresses. The lower 5 bits of the MTA and 
MLA codes, the primary address of the device, shall be identical (see IEC 625-1 , 39). If 
the device utilizes extended addressing, the talk and listen MSA's (my secondary 
addresses) shall also be identical. 



A device shall have a single primary address which may be set by the user to any value 
within the range of to 30. If the device utilizes extended addressing, the user shall also 
be able to set the single secondary address within the same range. 



The address of a device shall be settable independent from any other device's address 
even if the devices share common physical resources such as the same enclosure. 
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A device shall have a local means of selecting its IEC 625-1 primary address (and 
secondary address if extended addressing is used) that shall be retained during power-off. 
The device operator shall be capable of altering this address. 



The physical configuration, labelling, and positioning of the address selection mechanism 
shall follow the guidelines of IEC 625-1 annex L 

The device designer should avoid using address settings outside the range to 30. Any 
exceptions to this recommendation shall be documented with the associated behaviour. 



If hard switches are used to set the address and the address is apparently set to 31, the 
device shall operate in a manner that does not disrupt system bus traffic. 



Device documentation shall state when a user-initiated address change is recognized by 
the device. A device shall update its address at power-on. 



5.3 Talker requirements 

A device shall contain either the T5. T6, TE5, or TE6 subsets. These subsets require the 
basic talker with serial poll and unaddress if MLA. 

This standard assumes that the controller performs all talker addressing via MTA and 
unaddressing via MLA, OTA, and UNT. Talk-only mode capability is therefore not a 
requirement of this specification. The presence of a talk-only mode of operation (for 
example, in a controller-less system) is allowable, but operation in this mode is considered 
beyond the scope of this standard. 



5.4 Listener requirements 

A device shall contain either the L3, L4, LE3, or LE4 subsets. These subsets require the 
basic listener with unaddress if MTA. 

This standard assumes the controller performs all listener addressing via MLA and 
unaddressing via MTA and UNL. Listen-only mode capability is therefore not a 
requirement of this specification. The presence of a listen-only mode of operation (for 
example, in a controller-less system) is allowable, but operation in this mode is considered 
beyond the scope of this standard. 



Note the additional requirement for inactivating the Acceptor Handshake function on an 
ATN FALSE transition in LIDS (Listener Idle State). See 5.1.2. 



5.5 Service request requirements 

A device shall contain the SR1 (complete capability) subset and shall conform to the 
status handling requirements of clause 1 1 . 



28 



IS 10767 (Part 2) : 2001 
IEC 60625-2 (1993) 

5 . 6 Remote/Local requirements 

5.6.1 Control and operation definitions 

IEC 625-2 control functions and operations are classified using the source of control and 
method of annunciation. 

5.6.1.1 IEC 625-2 remote operation 

An IEC 625-2 remote operation is any operation of a device function in a system that is 
effected via program messages over the system interface. 



5.6.1.2 IEC 625-2 local operation 

An IEC 625-2 local operation is any operation of a device function that is not an IEC 625-2 
remote operation. 

An example is the actuation of a user-accessible switch, knob, button, touch-screen location, etc. that is 
physically attached to a device and used to control or program the device locally. 

Operation of a device via any other bus or interface connected to the device is 
considered to be local operation from the standpoint of the system. 

5.6.1.3 Local control 

A local control effects IEC 625-2 local operation of a device. 

Local controls include device inputs which are designed for control. 

Local controls and the accompanying remote/local requirements of this section are 
intended to apply only to local controls whose function can also be effected via IEC 625-2 
remote operation. 



Local controls whose function cannot be effected via IEC 625-2 remote operation are 
beyond the scope of this standard. 

The following control functions are explicitly excluded from categorization as local 
controls. 

1) Switching line power. 

2) The generation of the URQ (user request) message. 

5.6.1.4 External-control-signal 

An external-control-signal invokes device actions using a device port other than the 
system interface. External-control-signals are beyond the scope of this standard but may 
optionally function as a local control. External-control-signals, however, shall not violate 
the message exchange protocols of clause 6. 

An example of an external-control-signal is a digital voltmeter's external trigger which initiates a 
measurement. The results may then be read from the device. 
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5.6.1.5 Hard local control 

Hard local controls on a device have indicators (mechanical, positional, etc.) which cannot 
be changed by IEC 625-2 remote operation of the device. 

For example, an instrument may have a mechanical rotary switch that is used to select among three 
different modes of operation. The state of this switch is indicated by printed labels on the front panel of the 
device but remote messages cannot rotate the switch. 

5.6.1.6 Soft local control 

Any local control that is not a hard local control is a soft local control. 

For example, a physical (momentary contact) key on a device may be used to turn a device function on or 
off with alternate pushes. The on/off state is indicated by a light located by the switch. The light is 
controlled by the actual state of the device function. 

5.6.1.7 Programmable local control 

A local control of a device function that can be affected by IEC 625-2 remote operation as 
well as by IEC 625-2 local operation is a programmable local control. Programmable local 
controls may be hard or soft local controls. 



5.6.2 IEC 625-1 subset requirements 

A device that is capable of IEC 625-2 local and remote operation and utilizes 
programmable local controls shall contain the RL1 (complete capability including local 
lockout) subset of the IEC 625-1 Remote/Local function. 

A device that is incapable of IEC 625-2 local operation or does not utilize programmable 
local controls may contain the RLO (no capability) subset of the IEC 625-1 Remote/Local 
function. A device containing the RLO subset shall ignore all IEC 625-1 interface 
messages related to Remote/Local function state changes. 



5.6.3 Local-to-remote state transition requirements 

The transition from LOCS (Local State) or LWLS (Local With Lockout State) to REMS 
(Remote State) or RWLS (Remote With Lockout State) shall disable local operation of all 
programmable local controls. 

5.6.4 Remote-to-local state transition requirements 

The transition from REMS or RWLS to LOCS or LWLS shall enable local operation of all 
programmable local controls of the device. 

The transition shall also alter any hard local control functions so they match the hard local 
control indicator. After the transition, the device's front panel and state of control shall 
agree. 
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The transition shall not alter any soft local control functions. 



Setting the rt! local message TRUE with LLO false or ACDS (Accept Data State) inactive 
shall cause a device in REMS to change to LOCS (see IEC 625-1 , 1 1 .3.3.3). 



5.6.5 Local state operation 

In LOCS or LWLS. a device shall process all program messages so as to maintain 
consistency between the information presented to the local user and the actual state of 
the device. 

To avoid an inconsistency, a device shall do one of the following: 

1) Correct the inconsistent information presented to the local user. 

2) Remove the inconsistent information. 

3) Generate an execution error and discard the responsible <PROGRAM MESSAGE 
UNIT>. (See IEC 625-2 Status reporting protocols in clause 11.) 

Alternative 1 is the preferred choice. 

In LOCS or LWLS a device shall not be inhibited from sending a <RESPONSE 
MESSAGE> in response to a query previously received by the device. 

When a device is sent program messages while in local there are potential arbitration 
problems if front panel controls are manipulated. Application programs can avoid such 
problems by placing the device in remote. 



5.6.6 Remote state operation 

In REMS or RWLS, a device shall process all program messages. 

In REMS or RWLS, device-specific messages (not defined by this standard) may be sent 
to selectively enable specific local controls. Under this circumstance, the specified local 
controls are no longer locally inoperative. If specific hard local controls are enabled, the 
device's state of control and these hard local controls shall agree. 



In REMS or RWLS a device shall not be inhibited from sending a <RESPONSE 
MESSAGE> in response to a query previously received by the device. 

5.6.7 Operation independent of remote/local state 

The Remote/Local function shall be associated only with the enabling and disabling of 
local controls as defined in this section. Other device operation, such as updating the 
device state and associated local annunciation shall function independent of the 
remote/local state of the device. 
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5.6.8 Remote/local indicator requirements 

Devices with hard local controls shall incorporate a "Remote" indicator (IEC 625-1, 
annex L). 

For devices without hard local controls, the Remote indicator is optional. All indicators 
relating to remote/local transitions shall be labelled and function in accordance with the 
requirements of IEC 625-1, annex L. 



5.7 Parallel Poll requirements 

A device shall have either the PPO (no capability) or the PP1 (remote configuration) 
subset. A device with the PP1 subset shall conform to the requirements of 11.6. 



5.8 Device Clear requirements 

A device shall contain the DC1 (complete capability including selective device clear) 
subset. Specific IEC 625-2 requirements for the device's response to entering DCAS are 
specified in clause 6 and summarized below. 



A device entering DCAS (Device Clear Active State) via a DCL or SDC command 

Shall: 

1) Clear the Input Buffer and Output Queue. 

2) Reset the Parser, Execution Control, and Response Formatter (see 6.1 .4.2.6). 

3) Clear any command that prevents processing a *RST or other device commands. 

4) Discard all commands and queries deferred due to coupled parameters 
(see 6.4.5.3). 

5) Put the device into OCIS (Operation Complete Command Idle State) and into OQIS 
(Operation Complete Query Idle State) (see 12.5.2.1.1 and 12.5.3.1.1). 

6) Abort the *AAD and *DLF common commands (see clause 13). 

7) Put the device in the message exchange IDLE state (see 6.3.1.1). 

Shall not: 

1) Change any settings or stored data in the device except as stated above. 

2) Interrupt front panel I/O. 

3) Interrupt or affect any device operation in progress except as stated above. 

4) Change the status byte other than clearing the MAV bit as a consequence of 
clearing the Output Queue, see 11.2.1.2. 



32 



JS10767(Part2):2001 
IEC 60625-2 (1993) 



5.9 Device Trigger requirements 



A device may contain either the DTO <no capability) or the DT1 (complete capability) 
IEC 625-1 device trigger function. A device containing the DT1 subset shall implement the 
associated common command, *TRG as defined in 10.37. Use of the optional *DDT 
common command (see 10.4) affects the operation of *TRG and Group Execute Trigger 
(GET). 

5.10 Controller function requirements 

A device shall contain either no Controller function capability (CO) or contain a Controller 
function with the following subset options: C4 with C5, C7, C9, or C11. These subsets 
provide the capability to respond to SRQ. send IF messages, receive control, pass control, 
and take control synchronously. They specifically prohibit system controller capability, i.e., 
sending the IFC and REN interface messages. They optionally permit the capability of 
passing control to self and conducting a parallel poll. 



if a device contains any Controller function subset other than CO. then it shall also be able 
to pass and receive control by means of the protocols described in 17.4 and 17.5. 



See clause 15 for controller (as contrasted to device) requirements. 

5.11 Electrical requirements 

Implementation of the E2 electrical interface option (IEC 625-1, annex C) is 
recommended. Open collector drivers shall be used to drive the SRQ, NRFD, and NDAC 
signal lines. Three-state drivers should be used to drive the DAV, EOI, and ATN signal 
lines. A device is not allowed to drive REN or IFC. If the device is in PPAS (Parallel Poll 
Active State), the device shall use open collector drivers to drive the DI01-8 signal lines. 
When not in PPAS, the device should use three-state drivers to drive the DI01-8 signal 
lines. If a device needs to source handshake data bytes at a rate greater than 250 000 
bytes per second, the E2 option is required, IEC 625-1 clause 31. 



NOTE - Some integrated circuits may require external hardware to avoid driving the DIO lines during a 
parallel poll, even though the PP0 subset is implemented. 

5.12 Power-on requirements 

At power-on, device settings shall be either restored to their values when the device was 
last powered off, set to known states which are explicitly stated in the device 
documentation, or set to a state defined by the user and stored in local non-volatile 
memory. 

Device-specific commands may be provided to select whether device settings are restored 
or set to a known state at power-on. This standard defines one such command, Power-on 
Status Clear, (*PSC, see 10.25) which sets and clears the power-on-status-clear flag. 
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5.1 2.1 Items not affected by power-on 

A device shall not alter the following due solely to a power-on (receipt of the IEC 625-1 
pon local message). 

- The bus address. 

- Pertinent calibration data. 

- Data or device states which cause a change in the response to the following 
common queries: 

*IDN? (Identification Query, see 10.14) 

*OPT? (Option Identification Query, see 10.20) 

*PSC? (Power-on Status Clear Query, see 10.26) 

*PUD? (Protected User Data Query, see 10.28) 

*RDT? (Resource Description Transfer Query, see 10.31) 

5.12.2 Items dependent upon power-on-status-clear flag 

If the power-on-status-clear flag is FALSE, the Service Request Enable Register, the 
Standard Event Status Enable Register, and the Parallel Poll Enable Register shall not be 
affected by power-on. See *PSC command, clause 10.25. 



A device shall clear the Service Request Enable Register, the Standard Event Status 
Enable Register, and the Parallel Poll Enable Register at power-on if the power-on-status- 
clear flag is TRUE or if the *PSC command is not implemented. 



5.12.3 Items that may be affected by power-on 

At the discretion of the device designer, a device may alter the following at power-on. 

- Current device function states. 

- Status information. 

- *SAV/*RCL registers, see 10.33 and 10.29. 

- Macro definition defined with the *DDT command, see 10.4. 

- Macro definitions defined with the *DMC command, see 10.7. 

- Macro enabling with the *EMC command, see 10.8. 

- Address received with last *PCB command, see 10.21 . 

6 Message exchange control protocol 

The device message exchange protocol specifies how a device handles program and 
response messages. 

The term "controller" refers to the system element that is exchanging messages with the 
device. The requirements of this clause also apply to device-to-device communication. 
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The phrase ". . . the device shall (not) . . ." defines a requirement of this standard. The 
phrase ". . . the controller should (not) . . ." refers to conditions which will (not) happen 
under normal conditions. The device's response to both normal and exceptional 
conditions is defined by this standard. 



The term "Query Message", as used in this clause, is a <PROGRAM MESSAGE> which 
contains one or more <QUERY MESSAGE UNIT> elements. Note that all bracketed 
syntactic elements are defined in clauses 7 and 8. 



The terms "Command Error", "Execution Error", "Query Error", and "Standard Event Status 
Register" are defined in clause 11. 

6.1 Functional elements 

Figure 6-1 presents the relationship among the IEC 625-1 bus, the Message Exchange 
Interface described in this clause, the Status Reporting functions described in clause 11, 
and the device-specific functions provided by the device designer. 

6.1.1 IEC 625-1 bus 

The IEC 625-1 bus, shown in both figures 6-1 and 6-2, represents the physical IEC 625-1 
interface cable and drivers as defined in IEC 625-1. 

6.1.2 Status reporting 

The status reporting block appears only in figure 6-1. Figure 6-2 does, however, display 
the status messages sent from the Message Exchange Interface and the messages sent to 
the I/O Control. 

The status reporting block receives error and status messages from the Message 
Exchange Interface and Device Functions blocks. It also sends the STB, reqt, reqf, and 
IEC 625-1 ist messages to the I/O Control, so that it can respond to IEC 625-1 Serial Poll 
and Parallel Poll requests. The Status Reporting block is completely described in 
clause 1 1 . 

6.1.3 Message Exchange Interface 

The Message Exchange Interface deals with all IEC 625-1 device-dependent messages to 
and from the device. 

Figure 6-2 presents a logical model which describes the operation of the device's 
Message Exchange Interface. It is not intended to imply a particular physical implementation. 
Some handshaking signals between blocks have been omitted to reduce the complexity of 
the diagram. 
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Figure 6-1 - Device Status and Message Exchange overview 
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Figure 6-2 - Message Exchange Control Interface functional blocks 

6.1.4 I/O Control 

The I/O Control, shown in figures 6-1 and 6-2, interprets and decodes IEC 625-1 remote 
messages. Many of the functions of this block are provided by commercial integrated 
circuits that have been designed to implement the requirements of IEC 625-1 . 
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The I/O Control responds to IEC 625-1 Serial Poll and Parallel Poll requests as directed 
by the STB, reqt, reqf , and ist messages from the status reporting block, clause 1 1 . It 
generates the dcas, DAB, END, get, bav, and brq messages which are sent to the 
Message Exchange Interface, and receives the DAB and END messages from the 
Message Exchange Interface. 

6.1.4.1 I/O Control rules 

6.1.4.1.1 I/O Control sending data bytes 

When brq is TRUE and oq-empty is FALSE, the I/O Control shall remove one byte from 
the Output Queue, set brq FALSE, and send the byte to the controller using the IEC 625-1 
SH (Source Handshake) function. See clause 6.1.4.2.3. 

6.1 .4.1 .2 I/O Control receiving data bytes 

When bav is TRUE and lb-full is FALSE, the I/O Control shall set bav FALSE and then 
place the associated DAB and any accompanying END message into the Input Buffer 
using the IEC 625-1 AH (Acceptor Handshake) function. See clause 6.1.4.2.4. 



6.1.4.1.3 I/O Control receiving IEC 625-1 GET message 

When get is TRUE and lb-full is FALSE, the I/O Control shall set get FALSE and then 
place a GET message in the Input Buffer. 

NOTE - If the optional Trigger Control is implemented, the get message shall be sent to the Trigger 
Control rather than the Input Buffer. The get can be executed directly under certain conditions, see 6.1.11. 



6.1 .4.1 .4 I/O Control ordering of received messages 

The I/O control shall preserve the order of received messages, including data bytes 
(DAB's), END messages. Group Execute Trigger, Device Clear, and Selected Device 
Clear. 

The following example shows a design technique for preserving the order of received data 
bytes and the IEC 625-1 remote interface messages: DCL, SDC, and GET. 

Design the device's message interface for Device Trigger handling as follows: 



Design the IEC 625-1 AH function to wait in ACDS (Accept Data State) when the DT 
(Device Trigger) function enters the DTAS (Device Trigger Active State) after a GET is 
received and until the I/O Control sets the get message TRUE. This action is often called 
"NDAC bus holdoff. 

Have the I/O Control set bav FALSE and place the data byte in the Input Buffer before 
accepting the GET message when the bav and get messages are both TRUE. Since the 
new data byte associated with the bav message must have been received first with the 
bus being in a holdoff state during the receipt of the GET message, proper sequencing is 
guaranteed. 

Ensure the I/O Control accepts the GET message (sets get TRUE), before it releases the 
bus holdoff and allows the device's IEC 625-1 AH function to accept a new data byte. 
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Design the device's message interface for Device Clear handling as follows: 



Design the IEC 625-1 AH function to wait in ACDS when the DC (Device Clear) function 
enters the DCAS (Device Clear Active State) until the I/O Control sets the dcas message 
TRUE. 

Assure the I/O Control sets bav FALSE and discards the DAB before it releases the bus 
holdoff and allows the device's AH function to accept a new data byte. Since the new data 
byte associated with the bav message must have been received first with the bus being in 
a holdoff state during the receipt of the DCL or SDC messages, proper sequencing is 
guaranteed. 

6.1.4.2 I/O Control messages 

This subclause describes the action of the I/O Control IEC 625-2 local messages. 

6.1 .4.2.1 Data byte message (DAB) 

The DAB message is defined In IEC 625-1. It consists of eight bits that are either sent or 
received by the device while ATN is FALSE. 

6.1.4.2.2 End message (END) 

The END message is defined in IEC 625-1. It is sent with a DAB by setting EOI TRUE and 
ATN FALSE. 

6.1.4.2.3 Byte requested message (brq) 

The brq message indicates the readiness of the I/O Control to send a data byte to the 
controller. 

The I/O Control shall set brq TRUE after the IEC 625-1 SH function enters the IEC 625-1 
Source Generate state (SONS) and the T or TE function is in the Talker Active State 
(TACS). The brq message shall be set TRUE once and only once for each transition into 
SGNS. 

The I/O Control shall set brq FALSE when any of the following conditions occur: 

1) The I/O Control sends a data byte from the Output Queue to the controller (see 
clause 6.1.4.1.1). 

2) The device performs the INTERRUPTED action described in 6.3.2.3. 

3) The device performs the UNTERMINATED action described in 6.3.2.2. 

4) The I/O Control sets the dcas message TRUE. 

5) The Message Exchange Control enters the IDLE state from the DONE or DEADLOCK 
states. 

No other device or interface condition shall cause brq to be set FALSE. 

6.1.4.2.4 Byte available message (bav) 

The bav message indicates that the I/O Control has received a data byte and is ready to 
place it in the Input Buffer. 
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The I/O Control shall set bav TRUE after the IEC 625-1 L or LE function is in the Listener 
Active State (LACS) and the IEC 625-1 Acceptor Handshake function enters the Accept 
Data State (ACDS). The bav message shall be set TRUE once and only once for each 
transition from the Acceptor Ready State (ACRS) to ACDS. 



The I/O Control shall set bav FALSE when any of the following conditions occur: 

1) A data byte is placed in the Input Buffer. (If the device has a zero length Input 
Buffer, the I/O Control shall set bav FALSE when the data byte is sent to the Parser.) 
See 6.1.4.1.2. 

2) The dcas message is set TRUE. The associated data byte shall be discarded. 
No other device or interface condition shall cause bav to be set FALSE. See 6.1 .4.1 .3. 

6.1.4.2.5 Group execute trigger message (get) 

The IEC 625-2 get message signals the transition of the IEC 625-1 Device Trigger (DT) 
function to the DTAS (Device Trigger Active State). This transition occurs when an 
IEC 625-1 GET (Group Execute Trigger) remote interface message is received while the 
device was addressed to listen. The get message can be used to initiate a device-defined 
action or the action defined by the *DDT common command, see 10.4. 



The device shall process data bytes and GET messages in the order received, see 6.1 .4.1 .4. 



The standard specifies two methods for device triggering, the common command *TRG, 
(10.37), and the IEC 625-1 interface message GET. Typically, device triggering is used for 
two distinct purposes: 

1) For the properly sequenced initiation of a device-defined or user-defined action 
within a single addressed device. 

2) For the synchronized initiation of device-defined or user-defined actions within 
multiple addressed devices. 

For purpose 1, either GET or *TRG may be used for device triggering. The storage of 
either one in the Input Buffer ensures that the trigger will be executed in the correct 
sequence in relation to other commands. 

For purpose 2, where the required synchronization could be compromised by the 
software/firmware processing overhead, the get message may be used in conjunction with 
the optional Trigger Control Block, get will generate a trigger local t message for 
immediate execution by the device provided that the Input Buffer is empty and that the 
Parser and Execution Control are idle. If the Input Buffer is not empty, the GET message 
must be placed in the Input Buffer, and execution of the trigger deferred until previous 
commands have been executed. 



If the optional Trigger Control block, clause 6.1.11, is implemented, the I/O Control shall 
send the get message to it. Otherwise, the I/O Control shall place the GET message 
directly in the Input Buffer. 
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6.1 .4.2.6 Device clear active state message (dcas) 



The I/O Control shall set the dcas message TRUE after the device enters the Device 
Clear Active State (DCAS) defined by IEC 625-1. The device enters DCAS whenever it 
receives the Device Clear (DCL) remote command or it receives the Selected Device 
Clear (SDC) remote command while it is addressed to listen. 

When dcas is set TRUE, the Input Buffer and Output Queue shall be cleared, the Parser, 
Execution Control, and Response Formatter shall be reset, and the device shall enter the 
Message Exchange IDLE state. The device also enters OCIS (Operation Complete 
Command Idle State) and OQIS (Operation Complete Query Idle State), as in 12.5, and 
returns to normal operation after the *AAD or *DLF commands, clause 13. 



The I/O Control shall set the dcas message FALSE when these actions are completed and 
the Message Exchange Control enters the IDLE state. Device Clear requirements are 
summarized in clause 5.8. 

The device shall ensure that data bytes and DCL or SDC are processed in the order 
received. If the device receives a new data byte while dcas is TRUE, it shall not discard 
the data byte or set bav FALSE. 

6.1 .4.2.7 Response message terminator sent message (RMT-sent) 

The I/O Control block shall set the RMT-sent message TRUE when it has sent the 
<RESPONSE MESSAGE TERMINATOR>. 

Receipt of TRUE bav or brq messages shall cause the I/O Control to set the RMT-sent 
message FALSE. 

6.1.5 Input Buffer 

The Input Buffer, shown in figure 6-2, stores DAB's, GET messages, and END messages. 
The Input Buffer then delivers these messages to the parser in the order they were 
received from the I/O Control. The dcas message shall not be stored in the Input Buffer as 
this could result in the device not being able to respond immediately to dcas. 



The Input Buffer shall be implemented as a first-in first-out data structure. Data bytes, 
END, and GET messages are placed into the Input Buffer by the I/O Control as the device 
handshakes them from the IEC 625*1 bus. The details of when and how items are placed 
into the Input Buffer are described in 6.1.4.1.2, 6.1.4.1.3, and 6.1.4.1.4 on I/O Control 
Receiving. DAB's, END, and GET messages are removed from the Input Buffer by the 
parser at a rate consistent with the capabilities of the parser and the associated execution 
of commands. 



6.1.5.1 Input Buffer rules 

6.1 .5.1 .1 Input Buffer length 

The Input Buffer shall be equal to or greater than zero in length. The Input Buffer's length 
may be fixed at some number of bytes or program messages, or its length may vary. The 
Input Buffer length shall be specified in the user documentation. 
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The operation of the Input Buffer is transparent to application programs, except as a 
performance improvement. Devices which can accept program messages faster than they 
can execute them should have Input Buffers long enough to allow storing a reasonably 
sized program message. This buffering will allow application programs to send messages 
to the device and then continue to use the system bus for other purposes while the 
device is taking the time it needs to respond. 



EXAMPLE: A digital plotter responds to commands slowly due to the need to allow for pen movement. If a 
typical length program message for the device is 80 bytes, the device should have an Input Buffer of at 
least 80 bytes. 

The device designer must consider the application of the device when choosing an Input 
Buffer length. A larger Input Buffer is useful in smart, highly independent test instruments 
which use complex <PROGRAM MESSAGE> elements. These complex <PROGRAM 
MESSAGE> elements may require a significant time to process. In some systems, this 
time can be used for tasks other than waiting for this device to finish processing a 
<PROGRAM MESSAGE>. Increasing buffer length, however, requires the user to be more 
careful about synchronization within the system. 



If a zero length Input Buffer is used, the system Interface provides a source of 
synchronization. With this very short Input Buffer, the device can never fall behind the 
controller. If a DAB or GET is sent it will be processed immediately by the device. 

NOTE - Most commercial integrated circuits which implement the requirements of IEC 625-1 provide at 
least a one-byte internal data buffer. 

6.1 .5.1 .2 Input Buffer overflow 

The Input Buffer shall not overflow. If the buffer is full, the device shall not enter the 
IEC 625-1 Acceptor Ready State (ACRS) while in Listener Active State (LACS) (NRFD 
holdoff). After the Parser removes an Hern from the Input Buffer, the I/O control may 
accept another item from the system interface. No error shall be reported when the Input 
Buffer fills unless the device becomes deadlocked, see 6.3.1.7 and 6.5.7.4. 



6.1.5.1.3 Input Buffer clearing 

The Input Buffer shall be cleared when pon or dcas is TRUE. No device or interface 
condition is allowed to keep the clear operation from taking place. Except for the emptying 
during normal message processing and the actions of pon and dcas, no other interface or 
device condition shall be allowed to clear the Input Buffer. The Input Buffer is cleared to 
ensure that the device will be ready to receive and execute new <PROGRAM MESS AG E> 
elements following dcas. 

6.1.5.2 Input Buffer messages 

6.1 .5.2.1 Input Buffer empty message (ib-empty) 

The Input Buffer empty message, ib-empty, shall be TRUE when the Input Buffer is 
empty. The ib-empty message shall be FALSE at all other times. 
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6.1 .5.2.2 Input Buffer full message (ib-full) 



The Input Buffer full message, Ib-full, shall be TRUE when the Input Buffer is full. The 
ib-full message shall be FALSE at all other times. 

6.1.6 Parser 

The Parser, shown in figure 6-2, is the logical portion of a device which takes DAB's, END 
messages, and GET messages from the Input Buffer and analyzes them by separating out 
the various I EC 625-2 syntactic elements. It reports invalid syntax or headers to the Status 
Reporting block as Command Errors. The Parser converts syntactic elements into an 
internal representation which is sent to the Execution Control. The Parser also generates 
the eom and query messages when it recognizes these syntactic elements. 



A <PROGRAM MESSAGE> or <PROGRAM MESSAGE UNIT> is considered "parsed" 
when it has been analyzed by the Parser and the Parser is ready to continue analyzing 
other <PROGRAM MESSAGE UNIT> elements. 



6.1.6.1 Parser rules 

6.1.6.1.1 Parser errors 

The Parser shall detect Command Errors and report them to the Status Reporting block by 
setting the Command Error bit in the Standard Event Status Register, see 11.5.1.1.4. 



The Parser shall report a Command Error if it finds a syntax error in a <PROGRAM 
MESSAGE>, finds an unrecognized header, finds a parameter (<PROGRAM DATA> 
element) that is of the wrong type for its associated header, or encounters a GET 
message between the first byte of a <PROGRAM MESSAGE> and the <PROGRAM 
MESSAGE TERMINATOR>. 



When a Command Error is detected the device shall determine what will be done with any 
prior parsable elements of the same <PROGRAM MESSAGE>. The device is allowed to 
either discard or attempt to execute any such parsable elements. 



When a Command Error occurs the Parser shall discard all subsequent DAB's and GET 
messages until either: 

1) dcas is TRUE, or 

2) pon is TRUE, or 

3) eom is TRUE, or 

4) brq is TRUE and lb-empty is TRUE. 

The device designer may also choose to stop discarding DAB's and GET messages for 
other device defined conditions such as receipt of a comma, semicolon, or NL. The Parser 
is reset when any of these conditions is met. 
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NOTE - The device does not empty the Input Buffer after a Command Error. The Parser discards OABs 
and GET messages until it has detected one of the above conditions. The device will then resume normal 
parsing and executing of messages. 

6. 1 .6.1 .2 Parser resetting 

When the Parser is reset it shall interpret the next data byte it receives as the first byte of 
a <PROGRAM MESSAGE>. The Parser shall be reset when dcas or pon is TRUE. No 
device or interface condition is allowed to keep the reset operation from taking place. 
Other conditions that can reset the Parser are described in 6.1.6.1.1 . 



6.1.6.2 Parser messages 

6.1.6.2.1 Parsed message element 

A Parsed message element represents the device's internal representation of all or part 
of a <PROGRAM MESSAGE>. 

6.1 .6.2.2 End of message detected message (eom) 

The Parser shall set the end of message detected message, eom, TRUE when any of the 
following conditions occurs: 

1) When it receives an END message or a sequence of data bytes making up a 
<PROGRAM MESSAGE TERMINATOR* (7.5) from the Input Buffer, or 

2) After it parses a GET message, except when the GET occurs between the first byte 
of a <PROGRAM MESSAGE> and the <PROGRAM MESSAGE TERMINATOR* 
(6.1.6.1.1), or 

3) When the Trigger Control block has passed the trigger message to the Device 
Functions block. 

The Parser shall set the eom message FALSE when any of the following conditions occurs: 

1) When it is reset, or 

2) When it receives any other DAB or GET message from the Input Buffer. 

When the Parser has received a GET message from the Input Buffer or the Trigger Control 
block has passed a trigger message to the Device Functions block, any associated query 
message shall be set TRUE prior to setting the eom message TRUE. This ensures a 
proper sequence of execution of Message Exchange block transitions (figure 6-4). 



6.1 .6.2.3 Query Detected message (query) 

The Parser shall set the Query Detected message, query, TRUE when it receives any of 
the following: 

1) A sequence of data bytes making up a valid <QUERY PROGRAM HEADER* which 
is not a macro label, or 

2) A valid <COMMAND PROGRAM HEADER> or <QUERY PROGRAM HEADER> 
which is a macro label, where the macro is defined to include a <QUERY MESSAGE 
UNIT>, or 
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3) A GET message or *TRG command (or, if implemented, the trigger message), 
where the device implements the *DDT common command and the device trigger action 
defined by the *DDT command includes a <QUERY MESSAGE UNIT>, or 

4) A GET message or *TRG command (or, if implemented, the trigger message), 
where the device does not implement the *DDT common command and the device 
trigger action specified by the device designer is to generate a <RESPONSE 
MESSAGE>. 

"Valid <QUERY PROGRAM HEADER>" means that all characters up to and including the 
"?" represent a valid query mnemonic or macro label, and the characters immediately 
following the "?" form a legal separator or terminator. 



"Valid <COMMAND PROGRAM HEADER>* means that the header represents a valid 
command mnemonic or macro label, and the characters immediately following the 
mnemonic form a legal separator or terminator. 

EXAMPLE: 

•XYZ? is not a Valid <QUERY PROGRAM HEADER> because there is no "XYZ?" common query 

*ESR?X is not a valid <QUERY PROGRAM HEADER> because "X" is not a separator or terminator 

*IDN? 42 is a valid <QUERY PROGRAM HEADER> although the argument is incorrect. 

A Command Error will be generated for ai) of the three conditions listed above. 

The Parser shall set query FALSE when it is reset or when it receives any other DAB or 
GET message from the input Buffer. 

6.1.6.2.4 Parser idle message (p-idle) 

The Parser shall set the Parser idle message, p-idle, TRUE when the Parser has parsed 
all prior messages and is not actively processing a valid <COMMAND PROGRAM 
MESSAGE> or a valid <QUERY PROGRAM MESSAGE>. The Parser shall set p-ldle 
FALSE at all other times. 

6.1 .6.2.5 Parser Blocked message (p-blocked) 

The Parser shall set the Parser Blocked message, p-blocked, TRUE when the Parser is 
waiting for the Execution Control to finish processing the previous Parsed Message 
Element. The Parser shall set p-blocked FALSE at all other times. 

6.1.7 Execution Control 

The Execution Control block, shown in figure 6-2, deals with coupled parameters, 
see 6.4.5.3, queries which require a device action before they can generate a 
<RESPONSE MESSAGE>, and the device synchronization commands described in 
clause 12. The Execution Control determines when the device has enough information to 
execute a command. When the Execution Control has gathered enough information to 
initiate a device action, it sends an Executable Message Element to the Device Functions 
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block. The Execution Control may wait for the resulting device actions to complete 
(Sequential Command) or may continue processing commands (Overlapped Command), 
depending on the command. See 12.2. A <PROGRAM MESSAGE UNIT> is considered 
"executed" when it has been parsed and all corresponding device operations have been 
either completed (Sequential Command) or initiated (Overlapped Command). 



6.1.7.1 Execution Control Rules 

6.1 .7.1 .1 Execution Control Errors 

The Execution Control shall detect Execution Errors and report them to the Status 
Reporting block, see 11.5.1.1.5. 

6.1.7.1.2 Execution Control Resetting 

When the Execution Control is reset, prior history will not affect the execution of new 
<PROGRAM MESSAGE> elements received after dcas or pon. The Execution Control 
shall be reset when dcas or pon is TRUE. No device or interface condition is allowed to 
keep the reset operation from taking place. No other interface or device condition shall 
reset the Execution Control. 



6.1.7.2 Execution Control messages 

6.1.7.2.1 Executable Message Element 

An Executable Message Element is a directive to the Device Functions block to perform 
some device-specific action. These may take the form of Valid Query Requests or 
non-query Executable Message Elements. 



A Valid Query Request is an Executable Message Element which causes the Device 
Functions block to send data to the Response Formatter. A non-query element performs 
device-specific action but does not send Response Data to the Response Formatter. A 
single <PROGRAM MESSAGE UNIT> may cause more than one Executable Message 
Element to be sent. 

EXAMPLE: A query which starts a measurement and returns the results when the measurement is complete 
might require two Executable Message Elements: a non-query element to start the measurement and a 
Valid Query Request to send the results to the Response Formatter. 

The Execution Control also shall maintain the order of creating <RESPONSE MESSAGE 
UNIT> elements (as required by 6.4.5.4), by sending the Valid Query . Requests, 
associated with previous received <QUERY MESSAGE UNITS> that are already sent to 
the Device Functions block. 



6.1.7.2.2 Execution Control Idle message (ec-idle) 

The Execution Control shall set the Execution Control Idle Message, ec-idle, TRUE when 
the following conditions occur: 

1) All deferred commands have been executed, and 
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2) Execution Control is ready to accept a new command or query from the Parser, and 

a) Execution Control is reset, or 

b) All previous commands have been executed. 

The Execution Control shall set ec-idle FALSE at all other times. 
The Execution Control shall not set the ec-idle message TRUE. 

6.1.7.2.3 Execution Control Blocked message (ec-blocked) 

The Execution Control shall set the Execution Control Blocked message, ec-blocked, 
TRUE when it is ready to send a Valid Query Request to the Device Functions block but 
must wait for the Response Formatter and Device Functions block to process a prior Valid 
Query Request. The Execution Control shall set ec-blocked FALSE at all other times. 



6.1.8 Device Functions 

The Device Functions block, shown in both figures 6-1 and 6-2, contains all 
device-specific features and functions. It accepts Executable Message Elements from the 
Execution Control and performs the associated operations. 

6.1.8.1 Device Functions rules 

The Device Functions block shall accept Valid Query Requests from the Execution Control 
and shall send any required Response Data to the Response Formatter. All implemented 
I EC 625-2 common query commands and all device-specific query commands shall be 
handled in this manner. The Device Functions block shall report device status information 
to the Status Reporting block, clause 1 1 . 



6.1.8.2 Device Functions messages 

6.1.8.2.1 Power-On message (pon) 

The Device Functions block shall generate the pon local message as described in IEC 625-1. 



When pon is set TRUE, the Input Buffer and Output Queue shall be cleared, the Parser, 
Execution Control, and Response Formatter shall be reset, and the device shall enter the 
Message Exchange IDLE state. The device also enters OCIS (Operation Complete 
Command Idle State) and OQIS (Operation Complete Query Idle State), see 12.5. The pon 
message may also affect device-specific settings, see 5.12. The Device Functions block 
shall set the pon message FALSE when these actions are completed and the Message 
Exchange Control enters the IDLE state (see 6.3.1.1). 



6.1.8.2.2 Response Data 

Response Data is data provided by the device in response to <QUERY MESSAGE UNIT> 
elements that have been parsed and sent to the device in the form of Executable 
Message Elements (Valid Query Requests). Response Data is unformatted and may only 
be tokens representing the actual data to be formatted. 
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6.1 .9 Response Formatter 

The Response Formatter, shown in figure 6-2, builds a <RESPONSE MESSAGE> out of 
Response Message Elements from Valid Query Requests and response data. The 
<RESPONSE MESSAGE> is placed into the Output Queue. The Response Formatter's 
primary responsibility is to convert the internal representation of data elements into a 
sequence of data bytes according to the syntax rules in clause 8. 



6.1.9.1 Response Formatter rules 

The Response Formatter shall delimit all but the last <RESPONSE MESSAGE UNIT> in 
the <RESPONSE MESSAGE> with a <RESPONSE MESSAGE UNIT SEPARATOR> (";". 
see 8.4.1), and the last <RESPONSE MESSAGE UNIT> in the <RESPONSE MESSAGE> 
with the <RESPONSE MESSAGE TERMINATOR>. 



The Response Formatter shall be reset when dcas or pon is TRUE. No device or interface 
condition is allowed to keep the reset operation from taking place. The Response 
Formatter is reset so that any new <RESPONSE MESSAGE> elements will not be affected 
by conditions that existed before dcas or pon. 



6.1.9.2 Response Formatter messages 

6.1.9.2.1 Response Message Element 

A Response Message Element represents a device's internal representation of all or part 
of a <RESPONSE MESSAGE>. 

6.1 .9.2.2 Response Formatter Blocked message {rf-blocked) 

The Response Formatter shall set the Response Formatter Blocked message, rf-blocked, 
TRUE when it has a <RESPONSE MESSAGE UNIT> to be placed in the Output Queue 
and the Output Queue Full message, oq-full, is TRUE. The Response Formatter shall set 
rf-blocked FALSE at all other times. 

6.1.10 Output Queue 

The Output Queue, shown in figure 6-2, stores device-to-controller messages until the 
controller reads them. The Response Formatter places DAB and END messages into the 
Output Queue in response to query commands. These bytes are removed from the Output 
Queue as they are read by the controller. 



The Output Queue shown in figure 6-2 is a logical model. The Output Queue in a real 
device may store the individual bytes of the <RESPONSE MESSAGE> and/or tokens 
which represent <RESPONSE MESSAGE> elements. The device designer may also use 
other means of determining the response to be generated. 
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The device designer should provide an Output Queue large enough to handle reasonably 
long <RESPONSE MESSAGE> elements. The actual length chosen will depend on the 
characteristics of the device. To avoid overflowing a physical buffer, the device designer 
may defer the formatting of lengthy <RESPONSE MESSAGE> elements until the 
controller requests output. The device designer should ensure that the size and operation 
of the Output Queue are adequate to make a deadlock unlikely, see 6.5.7.4. 



6.1.10.1 Output Queue Rules 

The Output Queue shall be cleared when pon or dcas is TRUE. Note that this is not a 
Query Error. A Query Error shall be reported if the contents of the Output Queue are 
discarded for any other reason, see 6.3.1.7, 6.3.2.2, and 6.3.2.3. 



6.1.10.2 Output Queue messages 

6.1.10.2.1 Message Available message <MAV) 

The Output Queue shall send the MAV message to the Status Reporting block. As long as 
the Output Queue contains one or more bytes, MAV shall be TRUE. MAV shall be FALSE 
when the Output Queue is empty except as indicated below. See 11.2.1.2. 



When the device defers generation of Response Data until brq is TRUE, the MAV 
message shall be set TRUE when the device is ready to generate the Response Data. 
See 6.4.5.4. 

6.1.10.2.2 Output Queue Full message (oq-full) 

The Output Queue Full message, oq-full, shall be TRUE when the Output Queue is full. 
The oq-full message shall be FALSE at all other times. 

6.1.11 Trigger Control 

The Trigger Control block, shown in figure 6-2, is optional. It allows for high-speed 
hardware execution of GET messages without violating the rules of execution order. 



The GET message is commonly used to trigger a device-specific action or set of actions 
within a single addressed device. It is also used to trigger synchronized actions across 
multiple addressed devices. In this and other cases where it may be necessary to avoid 
the software/firmware execution time overhead incurred in the Input Buffer, Parser, and 
Execution Control blocks, the device designer may choose to implement the Trigger 
Control block. 



If the Trigger Control block is implemented, GET messages are not sent directly to the 
Input Buffer from the I/O Control. Instead get is sent to the Trigger Control Block which 
either sends a trigger message directly to the Device Functions, or places a GET in the 
Input Buffer. 
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6.1.11.1 Trigger Control rules 

The Trigger Control block shall detect the get message and check ib-empty (from the 
Input Buffer), p-idle (from the Parser), and ec-idle (from the Execution Control). If all four 
of these messages are TRUE, the Trigger Control block shall send the trigger message to 
the Device Functions. If either Ib-empty, p-idle, or ec-idle is FALSE, the Trigger Control 
block shall place the GET message in the Input Buffer. 

NOTE • The implementation of this optional Trigger Control block does not affect the device's response 
to GET nor relax the requirement of sequential processing of GET messages and DAB'S. This block only 
facilitates high-speed operation. 

6.1.12 Message Exchange Control 

The Message Exchange Control represents the interconnection of control messages 
between the Output Queue, Response Formatter, Input Buffer, Parser, Execution Control, 
I/O Control, and Device Functions blocks. 



6.2 Protocol overview 

This protocol overview describes the normal operation of the device message exchange 
protocol. It is not a detailed specification of the protocol, nor does it cover any protocol 
exceptions. The detailed specification of the device message exchange protocol begins 
in 6.3. 

Figure 6-3 shows the Message Exchange states and transitions encountered during 
normal operation of the device. It does not show certain required states and transitions 
associated with error recovery. Figure 6-4 and 6.3 describe the complete Message 
Exchange State Diagram with the dotted lines indicating the exception or error cases. 

Figures 6-3 and 6-4 use a different format from IEC 625-1 to reinforce that Message 
Exchange Control is done at a level higher than IEC 625-1. 
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dcae TRUE or 
ponTRUE 



IDLE 



waiting for message 



bav TRUE or 
gel TRUE or 
ib-empty FALSE 



torn TRUE 



READ 



I/O control receiving; parser and 
execution control active 



query TRUE 



QUERY 



I/O control receiving; parser, execution control, 
and response formatter active 



eom TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 



I 



brq TRUE and 
eom FALSE 



SEND 



I/O control sending; parser, execution control, 
and response formatter active 



eom TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 



RESPONSE 



I/O control sending; response 
formatter active 



RMT sent 



DONE 



waiting for next message 



bav TRUE or 
get TRUE 



Figure 6-3 - Message Exchange Control State Diagram (simplified) 

6.2.1 Initialization 

After power on or dcas, the Message Exchange Control shall wait in the IDLE state for a 
<PROGRAM MESSAGE> or GET message from the controller. The device shall not send 
a <RESPONSE MESSAGE> to the controller until it receives a valid Query Message from 
the controller. The controller will not normally attempt to read data from the device until it 
has sent a Query Message to the device. 
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6.2.2 Command processing 

When the device receives a <PROGRAM MESSAGE> from the controller while in the 
READ state: 

1) The I/O Control places the bytes of the message into the Input Buffer. 

2) The Parser removes the bytes from the Input Buffer and identifies the syntactic 
components of the message according to the syntax rules in clause 7. 

3) The Execution Control directs the Device Functions block to perform the actions 
associated with the message. 

The device may accept the bytes of another <PROGRAM MESSAGE> and place them in 
the Input Buffer before it has finished processing prior <PROGRAM MESSAGE> elements. 



6.2.3 Query processing 

Query processing is handled in the QUERY, SEND, RESPONSE, and DONE states. If a 
<PROGRAM MESSAGE> contains one or more queries, the device prepares a 
<RESPONSE MESSAGE> for the controller and places it in the Output Queue. After the 
controller finishes sending the Query Message to the device, it will address the device to 
talk and start reading the <RESPONSE MESSAGE>. The controller will not normally send 
another <PROGRAM MESSAGE> to the device until it has finished reading the 
<RESPONSE MESSAGE>. 



6.3 Message Exchange Control operation 

The Message Exchange Control State Diagram, figure 6-4, precisely defines how 
messages, described in 6.1.4, from the I/O Control cause the device to either receive or 
send messages. The interactions between the blocks in the Message Exchange Control 
Interface, figure 6-2, are shown in detail. Figure 6-3, shown before, includes only those 
states and transitions encountered during "normal" operation of the device. Figure 6-4 
includes the additional states and transitions necessary to detect Message Exchange 
Protocol errors. (These additional states and transitions are shown with dashed lines.) 



6.3.1 Message Exchange Control states 

At any time, the device is in one of the Message Exchange states. Depending on the 
state, various functional elements from figure 6-2 are active or inactive. Transitions are 
caused by the logical combination of messages from the functional elements. 

6.3.1.1 IDLE state 

In the IDLE state the device is waiting for a message from the controller. The next data 
byte received shall be interpreted as the beginning of a new <PROGRAM MESSAGE>. 
The Output Queue is empty. 

The Message Exchange Control shall enter the READ state when either: 

1) The I/O control sets bav TRUE, indicating that a data byte is available, or 

2) the I/O Control sets get TRUE, or 
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3) lb-empty is FALSE. This condition can occur when the device had entered the 
IDLE state from the READ or DEADLOCK state. 

The Message Exchange Control shall stay in the IDLE state when: 

1) brq is TRUE, and 

2) bav is FALSE, and 

3) get is FALSE, and 

4) lb-empty is TRUE. 

This occurs when the device has been addressed to talk and has nothing to say. The 
device shall perform the UNTERMINATED action described in 6.3.2.2. 

The Message Exchange Control shall stay in the IDLE state when either the dcas or pon 
is TRUE. The device shall perform the INITIALIZE action described in 6.3.2.1. 
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dcas TRUE or 
ponTRUE 

INITIAUZE 



eom TRUE 



Set 

brq FALSE 



IDLE 



waiting for message 



bavTRUEor 
get TRUE or 
ib-empty FALSE 



brq TRUE and 
bav FALSE and 



' get FALSE and 
I ib-empty TRUE 
t 



UNTERMINATED 
(Query error) 
set brq FALSE 



t. 



eom 

TRUE 



brq TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 



READ 



I/O control receiving; parser 
and execution control active 



I 



I/O control receiving; parser and execution J 
control active; discarding response J 



I DEADLOCK 

I 

l__ 



fbav TRUE or get TRUE) and 
ib-full TRUE and 
p-blocked TRUE and 
ec-blocked TRUE and 
rf-blocked TRUE 
oq-full TRUE 



query TRUE 



DEADLOCK (Query error) set brq FALSE 



I 



UNTERMINATED 
(Query error) 
set brq FALSE 



I 



eom TRUE and 
(bav TRUE or 
get TRUE or 
ib-empty FALSE) 



INTERRUPTED 
(Query error) 
set brq FALSE 



QUERY 



I/O control receiving; parser, execution 
control, and response formatter active 



eom TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 






bav TRUE or 
get TRUE or 
(eom TRUE and 
ib-empty FALSE) 



brq TRUE and 
eom FALSE 



INTERRUPTED 
(Query error) 
set brq FALSE 



SEND 



l/o control sending; parser, execution 
control, and response formatter active 






eom TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 



eom TRUE and 
bav FALSE and 
get FALSE and 
ib-empty TRUE 



UNTERMINATED 
(Query error) 
set brq FALSE 



bav TRUE or 
get TRUE 



INTERRUPTED 
(Query error) 
set brq FALSE 



RESPONSE 



I/O control sending; response 
formatter active 



RMT sent 



DONE 



waiting for next message 



bav TRUE or get TRUE 
set brq FALSE 



NOTE - Text below the line for the dotted line transitions indicates an action which the device performs 
during the transition. 

Figure 6-4 - Message Exchange Control State Diagram (complete) 
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6.3.1.2 READ state 



In the READ state the I/O Control shall read data bytes, GET, and END messages from 
the IEC 625-2 bus and place them in the Input Buffer as described in 6.1.4. The Parser 
and Execution Control are active and the Output Queue is empty. 



The Message Exchange Control shall enter the IDLE state when either dcas or pon is 
TRUE. The device shall perform the INITIALIZE action described in 6.3.2.1. 

The Message Exchange Control shall enter the IDLE state when each of the following 
conditions occur: 

1) brq is TRUE, and 

2) bav is FALSE, and 

3) get is FALSE, and 

4) lb-empty is TRUE. 

The device shall perform the UNTERMINATED action described in 6.3.2.2. 

NOTE - Entering the IDLE state without terminating the <RESPONSE MESSAGE> could result in a 
controller time out when the expected data is not sent. When this happens an *ESR? (Standard Event 
Status Register Query, 10.12) can be used to determine that no data was sent because a Query Error had 
occurred. 

The Message Exchange Control shall enter the IDLE state when the Parser sets eom 
TRUE. 

The Message Exchange Control shall enter the QUERY state when the Parser sets query 
TRUE. See 6.1.6.2.3. 

6.3.1.3 QUERY state 

In the QUERY state the Parser has recognized a valid query within a <PROGRAM 
MESSAGE>. The I/O Control shall continue to read data bytes from the IEC 625-1 bus and 
place them in the Input Buffer as described in 6.1.4.2.4. The Parser and Execution Control 
are active. The device may format its <RESPONSE MESSAGE> at this time, or may wait 
until the Message Exchange Control is in the SEND or RESPONSE states; see 6.4.5.4. 



The Message Exchange Control shall enter the SEND state when brq is TRUE and an 
eom has not been parsed. This transition indicates that the controller has started to read 
the response. 

The Message Exchange Control shall enter the RESPONSE state when the Parser sets 
eom TRUE, bav is FALSE, get is FALSE, and ib-empty is TRUE. This transition indicates 
that the device has finished processing the Query Message and is waiting for the 
controller to read the response. 
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The Message Exchange Control shall enter the DEADLOCK state when all of the following 
occur: 

1) the I/O Control sets bav or get TRUE, indicating that the controller is waiting to 
send data to the device, and 

2) lb-full is TRUE, and 

3) p-blocked is TRUE, and 

4) ec-blocked is TRUE, and 

5) rf-blocked is TRUE, and 

6) oq-full is TRUE. 

This transition shall cause the device to set the Query Error bit in the Standard Event 
Status Register, clear the Output Queue, and reset the Response Formatter. 



The Message Exchange Control shall enter the READ state when the following conditions 
occur: 

1) eom is TRUE and either 

2) bav is TRUE, or 

3) get is TRUE, or 

4) lb-empty is FALSE. 

The device shall perform the INTERRUPTED action described in 6.3.2.3. 

The Message Exchange Control shall enter the IDLE state when either dcas or pon is 
TRUE. The device shall perform the INITIALIZE action described in 6.3.2.1. 

6.3.1.4 SEND state 

In the SEND state the controller has started to read the <RESPONSE MESSAGE> from 
the device. The device continues to parse and execute the Query Message stored in the 
Input Buffer. The Response Formatter prepares the <RESPONSE MESSAGE>, and places 
it in the Output Queue. The I/O Control shall send data bytes from the Output Queue to 
the controller as described in 6.1 .4.2.3. 

The Message Exchange Control shall enter the RESPONSE state when eom is TRUE, bav 
is FALSE, get is FALSE, and ib-empty is TRUE. 

The Message Exchange Control shall enter the IDLE state when all of the following 
conditions occur: 

1) eom is TRUE, and 

2) bav is FALSE, and 

3) get is FALSE, and 

4) Ib-empty is TRUE. 

The device shall perform the UNTERMINATED action described in 6.3.2.2. 
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The Message Exchange Control shall enter the READ state when any of the following 
conditions occur: 

1) bavisTRUE, or 

2) get is TRUE, or 

3) the Parser sets eom TRUE and lb-empty is FALSE. 

This condition indicates that the controller started sending a new message before reading 
all of the response. The device shall perform the INTERRUPTED action described 
in 6.3.2.3. 

The device shall enter the IDLE state when either dcas or pon is TRUE. The device shall 
perform the INITIALIZE action described in 6.3.2.1. 

6.3.1.5 RESPONSE state 

In the RESPONSE state the Parser has received a <PROGRAM MESSAGE 
TERMINATOR> and the device is sending the complete <RESPONSE MESSAGE> to the 
controller. The Response Formatter formats the <RESPONSE MESSAGE> and the I/O 
Control sends data bytes from the Output Queue to the controller as described 
in 6.1.4.2.3. 

The Message Exchange Control shall enter the DONE state when the complete 
<RESPONSE MESSAGE> including the <RESPONSE MESSAGE TERMINATOR> has 
been sent. 

The Message Exchange Control shall enter the READ state when either of the following 
conditions occur: 

1) bavisTRUE, or 

2) get is TRUE. 

This transition indicates that the controller attempted to send a new message before reading 
the complete <RESPONSE MESSAGE>. The device shall perform the INTERRUPTED action 
described in 6.3.2.3. 

The Message Exchange Control shall enter the IDLE state when either dcas or pon is 
TRUE. The device shall perform the INITIALIZE action described in 6.3.2.1. 

A device may have nothing to say while the Message Exchange Control is in the 
RESPONSE state if all of the queries in the Query Message failed to generate any 
<RESPONSE DATA> because of syntax (Command), semantic (Execution), or 
Device-specific errors. The device shall not send a <RESPONSE MESSAGE TERMINATOR> 
to the controller. The Message Exchange Control shall remain in the RESPONSE state 
until it either receives a data byte or GET message from the controller or the pon or dcas 
message becomes TRUE. 

6.3.1.6 DONE state 

In the DONE state the device has finished sending a <RESPONSE MESSAGE> to the 
controller and is waiting for a new <PROGRAM MESSAGE> or GET from the controller. 
The Parser, Execution Control, and Response Formatter are inactive and the Input Buffer 
and Output Queue are empty. 

57 



IS 10767 (Part 2): 2001 
IEC 60625-2 (1993) 

The Message Exchange Control shall enter the READ state and set brq FALSE when 
either: 

1) bav is TRUE, indicating that a new <PROGRAM MESSAGE> has been started, or 

2) get is TRUE. 

The Message Exchange Control shall enter the IDLE state when either dcas or pon is 
TRUE. The device shall perform the INITIALIZE action described in 6.3.2.1. 

6.3.1.7 DEADLOCK State 

In the DEADLOCK state the device has been asked to buffer more data than it has room 
to store. The Output Queue was full, blocking the Response Formatter, Execution Control, 
and Parser. The Input Buffer was full, and the controller was waiting to send more data 
bytes to the device. 

The Message Exchange Control breaks the deadlock by clearing the Output Queue and 
resetting the Response Formatter as it enters the DEADLOCK state (transition from 
QUERY to DEADLOCK, see 6.3.1.3). The Message Exchange Control also sets the Query 
Error bit in the Standard Event Status Register. While in the DEADLOCK state the 
Message Exchange Control shall continue to parse and execute <PROGRAM MESSAGE 
UNIT> elements as usual, except that it shall discard query responses rather than placing 
them into the Output Queue. 



The Message Exchange Control shall enter the IDLE state and set brq FALSE when either 
of the following conditions occur: 

1) The Parser sets eom TRUE. When the controller attempts to read the 
<RESPONSE MESSAGE>, the device shall not send any data bytes. Note that not 
sending any data, bytes may cause the controller to time out. When this happens, 
an *ESR? (Standard Event Status Register Query, see 10.12) can be used to 
determine that no data was sent because a Query Error had occurred. 

2) Either dcas or pon is TRUE. The device shall perform the INITIALIZE action 
described in 6.3.2.1. 

6.3.2 Message Exchange Control transition actions 

Certain transitions among the states are important enough to be named. The actions 
caused by the transitions are essential for reliable error detection, reporting, and recovery. 



6.3.2.1 INITIALIZE action 

The INITIALIZE action is executed when the IEC 625-2 communication channel is to be 
cleared. 

The device shall perform each of the following actions: 

1) Clear the Input Buffer, and 

2) Clear the Output Queue, and 

3) Reset the Parser, and 
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4) Reset the Execution Control, and 

5) Reset the Response Formatter. 

No error condition shall be reported. 

6.3.2.2 UNTERMINATED action 

The UNTERMINATED action is executed when the controller attempts to read a 
<RESPONSE MESSAGE> from the device without first having sent a complete Query 
Message, including the <PROGRAM MESSAGE TERMINATOR>, to the device. 

The device shall perform each of the following actions: 

1) Set the Query Error bit in the Standard Event Status Register. 

2) Clear the Output Queue. 

3) Optionally execute any <PROGRAM MESSAGE UNIT> elements from the 
incomplete message. If it executes any of the <PROGRAM MESSAGE UNIT> elements, 
it shall also execute all previous <PROGRAM MESSAGE UNIT> elements from the 
same message. 

4) Discard any partially parsed <PROGRAM MESSAGE UNIT> so that the Parser will 
be ready to parse a new <PROGRAM MESSAGE UNIT>. 

5) Set brq FALSE. 

6.3.2.3 INTERRUPTED action 

The INTERRUPTED action is executed when the device is interrupted by a new 
<PROGRAM MESSAGE> before it finishes sending a <RESPONSE MESSAGE>. 

The device shall perform each of the following actions: 

1) Set the Query Error bit in the Standard Event Status Register, and 

2) Clear the Output Queue, and 

3) Reset the Execution Control and Response Formatter so that, when the device 
receives a new <QUERY MESSAGE UNIT>, the correct <RESPONSE MESSAGE> will 
be sent, and 

4) Set brq FALSE. 
6.4 Protocol rules 

6.4.1 Program message transfer 

The device shall exchange messages with the controller in accordance with IEC 625-1 
and the syntax rules of clauses 7 and 8. 

The device shall not treat IFC or any ATN-true IEC 625-1 command or address, except for 
SDC addressed to the device, DCL or GET, as a message terminator. The controller may 
freely intersperse ATN-true commands (except DCL. SDC, and GET) and messages 
addressed to other devices among the bytes of messages to or from the device without 
affecting the contents or interpretation of a message. Such commands may cause the 
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device to suspend sending a device-to-controller message, but. when the device re-enters 
TACS, the device shall resume sending the rest of the message. The device shall also be 
undisturbed in processing a controller-to-device message that is suspended due to the 
conditions mentioned. The device shall resume accepting the rest of a message when the 
device is again addressed to listen and ATN is set FALSE. 



6.4.2 Message source independence 

The device shall interpret received messages without reference to the source of the message. 

Devices (e.g. bus repeaters or diagnostic instruments) may record talker and listener 
addresses and may return such a record in response to a query, but shall not ignore 
messages or interpret them differently on the basis of such information. 

6.4.3 Message exchange sequence 

The controller and device exchange complete <PROGRAM MESSAGE> and 
<RESPONSE MESSAGE> elements except as described under "Protocol exceptions", 
see 6.5. 

Message exchanges are initiated by the controller. The device shall not generate a 
<RESPONSE MESSAGE> until it receives one of the following Query Messages: 

1) A sequence of data bytes making up a valid <QUERY PROGRAM HEADER> which 
is not a macro label. 

2) A valid <COMMAND PROGRAM HEADER> or <QUERY PROGRAM HEADER> 
which is a macro label, where the macro is defined to include a <QUERY 
MESSAGE UNIT>. 

3) A GET message or *TRG command, where the device implements the *DDT 
common command and the device trigger action defined by the *DDT command 
includes a <QUERY MESSAGE UNIT>. 

4) A GET message or *TRG command, where the device does not implement the *DDT 
common command and the device trigger action specified by the device designer is 
to generate a response message. 

See 6.1.6.2.3. 

The device shall generate exactly one <RESPONSE MESSAGE> for each Query Message 
it receives. A <QUERY MESSAGE UNIT> may return one or more <RESPONSE 
MESSAGE UNIT> elements. 

EXAMPLE: 

A DVM is asked to take five separate readings and return them in a single <RESPONSE MESSAGE>. 

Command: MEAS_FIVE? <PMT> 
Response: 6; 2; 9; 2; 4 <RMT> 
A DVM is asked to return all its setting information about its OHMS function. 
Command: OHMS.SET? <PMT> 
Response: RANGE 100; AVGS 10;. . .; AUTOZERO 1 <RMT> 

Device documentation shall clearly indicate any <QUERY MESSAGE UNIT> which returns 
more than one <RESPONSE MESSAGE UNIT>. 



60 



IS 10767 (Part 2): 2001 
IEC 60625-2 (1993) 

The device shall interpret a GET message in the same way as a <PROGRAM MESSAGE> 
element. The device shall report a Command Error if it encounters a GET message 
between the first byte of a <PROGRAM MESSAGE> and the <PROGRAM MESSAGE 
TERMINATOR>. 

The controller should not attempt to read any part of a <RESPONSE MESSAGE> from 
the device until it has sent the entire Query Message to the device. The controller 
should not send any part of another <PROGRAM MESSAGE> to the device until it has 
read the entire <RESPONSE MESSAGE> from the device. The device shall detect the 
controller's failure to follow this protocol and shall act as described under "Protocol 
exceptions", see 6.5. 

After pon or after receiving dcas, the device shall wait for a <PROGRAM MESSAGE> 
from the controller. During this time, it may assert the IEC 625-1 SRQ (service request) 
signal and shall interpret and respond to IEC 625-1 interface messages (e.g. Serial Poll) 
but shall not automatically generate any <RESPONSE MESSAGE> elements. 



At any given time, the device is doing one of the following things: 

1) The device is idle, waiting for a message from the controller. The controller may 
be idle or may be communicating with some other device(s) on the system bus. 
(The Message Exchange Control is in the IDLE or DONE state.) 

2) The device is receiving a message from the controller. The controller may 
interrupt the transfer to perform a serial poll or to communicate with other devices, 
but should not attempt to read data bytes from the device until it has sent a 
<PROGRAM MESSAGE TERMINATOR>, see 7.5. to the device. (The Message 
Exchange Control is in the READ, QUERY, or DEADLOCK state.) 

3) The device is sending a <RESPONSE MESSAGE> to the controller. The 
controller may interrupt the transfer to perform a serial poll or to communicate with 
other devices, but should not attempt to send data bytes to the device until it has 
received a <RESPONSE MESSAGE TERMINATOR>, see 8.5, from the device. 
(The Message Exchange Control is in the SEND or RESPONSE state.) 

6.4.4 Compound queries 

One or more <QUERY MESSAGE UNIT> elements can be placed in a single <PROGRAM 
MESSAGE>, clause 7. Also, the device is allowed to generate one or more <RESPONSE 
MESSAGE UNIT> elements for each <QUERY MESSAGE UNIT> received. The 
<RESPONSE MESSAGE UNIT SEPARATOR> (semicolon ";", see 8.4.1) shall be used to 
separate <RESPONSE MESSAGE UNIT> elements within the complete compound 
<RESPONSE MESSAGE>. The <RESPONSE MESSAGE TERMlNATOR>, defined in 8.5 
as NL A END, shall terminate the last <RESPONSE MESSAGE UNIT>. Since the required 
terminator for a <RESPONSE MESSAGE UNIT> is dependent upon whether a subsequent 
<RESPONSE MESSAGE UNIT> will be in the same <RESPONSE MESSAGE>, the device 
is not able to terminate each <RESPONSE MESSAGE UNIT> until the Parser receives 
either another <QUERY MESSAGE UNIT> or <PROGRAM MESSAGE TERMINATOR>. 
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Compound queries shall not span more than one complete <PROGRAM MESSAGE>. If a 
compound query exceeds a device's ability to hold the associated <RESPONSE 
MESSAGE> in the Output Queue, the device's Response Formatter, Execution Control, 
and Parser may become blocked waiting until room is available. If the Input Buffer 
becomes full while the Parser is suspended, a buffer deadlock will occur, see 6.5.7.4. 



NOTE - If any of the <QUERY MESSAGE UNIT> elements of a compound query returns more than one 
<RESPONSE MESSAGE UNIT>, an application program cannot use the semicolon, *;", delimiter to 
distinguish the end of the response to each <QUERY MESSAGE UNIT>. 



6.4.5 Message order requirements 

6.4.5.1 Execution order of program messages 

The device shall execute <PROGRAM MESSAGE> elements in the order received. 
(See 6.1.7 for definition of execute.) Execution of individual parsable elements may be 
done as they are received. The device may also wait until either a <PROGRAM MESSAGE 
UNIT SEPARATOR> or a <PROGRAM MESSAGE TERMINATOR> is parsed before 
executing preceding <PROGRAM MESSAGE UNIT> elements. The device shall not execute 
any <PROGRAM MESSAGE UNIT> before executing all prior <PROGRAM MESSAGE 
UNIT> elements, except as described under "Device parameter couplings", see 6.4.5.3. 
The device shall execute all the <PROGRAM MESSAGE UNIT> elements of a given 
<PROGRAM MESSAGE> before executing any <PROGRAM MESSAGE UNIT> elements 
of a successive <PROGRAM MESSAGE>. 



6.4.5.2 Execution order of intermixed GET messages and <PROGRAM MESSAGE> 
elements 

The device shall execute GET messages in the same order as <PROGRAM MESSAGE> 
elements. If the device receives a GET message while parsing or executing a prior 
message, execution of the GET message shall be delayed until the prior messages have 
been executed. 

6.4.5.3 Device parameter couplings 

Coupled parameters are device functions which interact with each other in a 
device-specific manner. Problems can arise because the prior state of the device can 
affect the device's response to the programming of a coupled parameter, ideally, the 
device shall guarantee that a complete <PROGRAM MESSAGE> containing a set of valid 
settings for coupled parameters will be accepted independent of the prior setting of any of 
the coupled parameters. 

EXAMPLE: A power supply can have its current and voltage set to a wide range of values with the 
requirement that the product of the two parameters is less than 100 watts. Assume the voltage is set to 
100 votts, and the current to 1 amp. The device should allow the application programmer to send the 
following message and not have an error reported. 

CURRENT 100; VOLTAGE 1 NL A END 
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To accomplish sequence independence of coupled parameters, the Execution Control may 
buffer parsed message units and defer execution until eom or some device-specific 
command is received. The device may also use other techniques to achieve the same 
goal. The requirement that <PROGRAM MESSAGE UNIT> elements are executed in order 
of reception is relaxed under these circumstances. 



If the coupled parameter <PROGRAM MESSAGE> elements are not contiguous then the 
final results are unspecified. In this case the device may report an Execution Error if the 
parameter coupling criterion is violated before the complete set of coupled parameters has 
been executed. 

Some devices may have parameter couplings that are beyond the scope of the device 
parameter coupling requirements of this clause. 

6.4.5.4 Generation, of Response Message data 

Device designers may choose to generate the bytes of a <RESPONSE MESSAGE> at the 
time the controller reads a message rather than immediately following the execution of a 
Query Message. Sending large amounts of response data may require this technique. In 
such cases, the contents of the <RESPONSE MESSAGE> will represent the state of the 
device at the time the controller reads the response, rather than at the time the query 
was parsed. Device documentation shall indicate the query responses which will be 
evaluated at the time data is actually read. 



When the device designer chooses to defer the generation of response data until brq is 
TRUE, the device shall set the MAV message TRUE at the point when the device is ready 
to respond to the controller's request for data. Thus, an application program can always 
rely on receiving the MAV message, via the status reporting capability, as a signal to 
begin a device-to-controller transfer, see 11.5.2.1. 



<RESPONSE MESSAGE> elements shall be sent to the controller in the same order that 
their associated <QUERY MESSAGE UNIT> elements were sent to the device. Under no 
condition shall the device send the response to a <QUERY MESSAGE UNIT> before 
responding to a prior <QUERY MESSAGE UNIT>, except when the prior response was 
aborted due to one of the protocol exceptions described in 6.5. 



6.5 Protocol exceptions 

6.5.1 Aborted messages 

<PROGRAM MESSAGE> and <RESPONSE MESSAGE> elements shall be aborted by 
dcas or pon. 

6.5.2 Addressed to talk with nothing to say 

If the I/O Control sets brq TRUE while the Message Exchange Control is in the READ or 
IDLE state, the device has been addressed to talk with nothing to say. The device shall 
perform as indicated in 6.3.2.2, UNTERMINATED action. 
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If the I/O Control sets brq TRUE while the Message Exchange Control is in the 
RESPONSE state but all of the queries in the Query Message failed to generate any 
<RESPONSE DATA> because of syntax (Command), semantic (Execution), or device- 
specific errors, the device has been addressed to talk with nothing to say. The device 
shall perform as indicated in 6.3.1 .5. 

NOTE - The device may be unable to send data when it is addressed to talk even if no error condition 
exists. This can occur because the device has deferred the preparation of the response data until an 
internal operation is complete or an "External Control Signal" is received. This is not an error condition and 
a Query Error shall not be reported. If the controller continues to wait for the data, the device will send it 
when it is available. 

6.5.3 No listener on bus 

If the device's IEC 625-1 Source Handshake function is in the Source Delay State (SDYS) 
and the Not Data Accepted (NDAC) and Not Ready For Data (NRFD) signals are both 
passive false, the device shall not send any data bytes or take any action that would 
affect subsequent activity on the IEC 625-1 bus. The device shall wait for a listener to 
assert NDAC TRUE or for the controller to take control. The device designer may report 
this condition to the user by means other than the system Interface. 

NOTE - This rule applies only to devices which are not the controller-in-charge. Controllers are required 
to report this condition to the application (see 15.2). 

6.5.4 Command Error 

A Command Error is generated under the conditions defined in 6.1.6.1.1. When the Status 
Reporting Control receives a Command Error, it shall set the Command Error bit in the 
Standard Event Status Register, see 11.5.1.1.4. 

6.5.5 Execution Error 

An Execution Error occurs under the conditions defined in 11.5.1.1.5. When the Execution 
Control detects an Execution Error, the Status Reporting Control shall set the Execution 
Error bit in the Standard Event Status Register. The device shall continue parsing and 
executing commands. 

6.5.6 Device-specific Error 

Device-specific Errors are defined in 11.5.1.1.6. These errors shall have no effect on the 
message exchange protocol defined in this section. 

6.5.7 Query Error 

Query errors are reported by setting the Query Error bit in the Standard Event Status 
Register as defined in 11.5.1.1.7. The device shall report a Query Error when the 
controller fails to follow the Message Exchange Control Protocol under any of the 
conditions defined in 6.3.1.7, 6.3.2.2, and 6.3.2.3. 



6.5.7.1 Incomplete command or query received 

The device shall detect an incomplete command or query when the I/O Control sets brq 
TRUE and the Parser has received at least one byte of a <PROGRAM MESSAGE>, but 
not eom, and the Input Buffer is empty. The device shall respond as indicated in 6.3.2.2, 
UNTERMINATED. 
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6.5.7.2 Interrupted Response 



If the device receives a data byte or a GET message following a Query Message but 
before the device has sent the <RESPONSE MESSAGE TERMINATOR>, the 
INTERRUPTED action shall be performed. When this happens, the device shall abort the 
rest of the response and respond as indicated in 6.3.2.3, INTERRUPTED. 



6.5.7.3 Query Message Units separated by the Program Message Terminator 

When an application program sends a device a Query Message, properly terminated with 
a <PROGRAM MESSAGE TERMINATOR>, and sends another <PROGRAM MESSAGE> 
without first reading the entire <RESPONSE MESSAGE>, the device shall respond as 
indicated in 6.3.2.3, INTERRUPTED action. 



Warning: If the application program sends two Query Messages without reading the 
response from the first, and then attempts to read the response to the second, it may 
receive some data bytes from the first response followed by the complete second 
response. The result may or may not be a syntactically correct <RESPONSE 
MESSAGE>. This happens when the system timing allows the controller to send the 
second Query Message and begin its read operation before the Parser detects the end 
of the first Query Message. In this case, the Message Exchange Control enters the 
SEND state and starts to send the first response to the controller. When the Parser 
reaches the end of the first Query Message, the device is INTERRUPTED and starts to 
process the second query. 

To avoid the above condition, application programs should not send Query Messages 
to a device without reading the associated <RESPONSE MESSAGE>. When this 
cannot be avoided as in exception handling, a device clear should be used before a 
new Query Message is sent. This will assure that any fragmentary response, from a 
prior <RESPONSE MESSAGE>, will not be sent by the device. 



6.5.7.4 Buffer Deadlock 

Under some circumstances a device may be unable to completely generate a 
<RESPONSE MESSAGE>. The device is deadlocked when it cannot accept another data 
byte of a <PROGRAM MESSAGE> from the controller because its Input Buffer and Output 
Queue are both full and the controller cannot read the device's <RESPONSE 
MESS AG E> until it has completed sending its Query Message. 



The device shall respond to a Buffer Deadlock as indicated in 6.3.1.7, DEADLOCK. 
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6.5.7.5 Query after indefinite response 

Certain compound queries may attempt to generate an illegal <RESPONSE MESSAGE>. 
If a <QUERY MESSAGE UNIT> which generates an indefinite response (either an 
INDEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA or ARBITRARY ISO 7-bit 
RESPONSE DATA) is not the last <QUERY MESSAGE UNIT> in a <PROGRAM 
MESSAGE>, the device shall report a Query Error and not send the response from the 
following <QUERY MESSAGE UNIT> elements. The device may optionally either format 
or not format the response data which is discarded. Once the device recognizes the eom 
and sends the <RESPONSE MESSAGE TERMINATOR>, the message exchange protocol 
is re-established, see 6.3. 



7 Device listening formats 

7. 1 Overview 

This clause discusses the formatting of programming messages received by a device from 
its system interface. This formatting occurs on two levels. The higher is the "functional" 
level where each element has functional importance. This functional level is required for 
designers of the device command set. The lower-level formatting represents the actual 
bus "encoding" required to transmit a functional element. This latter information is 
necessary for designers of device parsers. 



7.1.1 Device command set generation 

Allowable IEC 625-2 program messages are composed of sequences of program message 
units, each unit representing a program command or query. Each program command or 
query is composed of a sequence of functional syntactic elements. Legal IEC 625-2 
program commands and queries are created from functional element sequences 
generated by traversing the functional syntax diagram illustrated in figures 7-1 to 7-6. 



Some commands and queries of universal instrument system application have been 
defined by this standard. They are the common commands described iri clause 10. These 
common commands and queries are specific path selections through the functional syntax 
diagram. The remaining commands are device-specific and are generated by the device 
designer using the functional syntax diagram and the needs of the device. The functional 
elements include separators, terminators, headers, and data types. Each element type is 
discussed in detail in 7.4 to 7.7. 



Legal IEC 625-2 program command structures at the functional level shall only be 
generated by traversing the functional syntax diagram. 
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7.1.2 Encoding syntax 
7.1.2.1 Allowable syntax 



A device-defined or common program command or query is sent to the device over the 
system Interface as a sequence of data bytes. The allowable byte sequences for each 
functional element are defined in the encoding syntax diagram accompanying each 
element. Alternate, but semantically equivalent paths are shown in each of these encoding 
syntax diagrams. "Data Fields" are device-definable within specified encoding limits. 
Allowable sequences for each functional element are generated by traversing the 
respective encoding syntax diagram. 



For allowable functional element sequences, a device sjiall accept and correctly interpret 
functional elements which follow the encoding sequence. All equivalent paths, as defined 
for each functional element, shall be accepted by the device's parser. 



7.1 .2.2 Illegal syntax - Command Error 

A byte sequence which does not follow encoding syntax rules as defined in 7.1.2.1 shall 
not be interpreted as a functional element, but shall generate a Command Error. 



A functional element sequence that is not an allowable IEC 625-2 program message as 
defined in 7.1.1 shall not be interpreted as a program command or query but shall result in 
the generation of a Command Error. 



How Command Errors are reported is described in clause 11, Device Status Reporting. 
Parser interaction with, and recovery from, Command Errors are described in clause 6, 
Device Message Exchange Protocols. 



7.1 .2.3 Rationale for encoding syntax flexibility 

For program data, the encoding syntax diagrams are designed to allow a variety of 
semantically equivalent encodings of a functional element. 

This flexibility is included for: 

1) Human-readability. Program commands typically appear in program code and thus 
need a reasonable degree of readability. 

2) Human-generation. Program commands are typically generated by the programmer 
and not the controller. Thus, a degree of formatting flexibility is desirable to allow 
commonly used formatting variations. 
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7.2 Notation 

7.2.1 Diagraming syntactic flow 

Syntactic elements are connected by lines with directional symbols to indicate the flow. 
Flow through the syntax diagrams generally proceeds from left to right. 



When an element or elements is repeatable, a reverse, right-to-left path will be shown 
around and above the element(s). 

When an element or elements can be bypassed, a left-to-right path will be shown around 
and below the element(s). 

The path branches when there is a choice of elements. 

EXAMPLE: 




Allows the following combinations of elements A, B and C. 

AC 
C 

BCCCCC 
CCC 

NOTE - The element C may be repeated indefinitely. 

7.2.2 Syntactic elements 

7.2.2.1 Terminal syntactic elements 

Terminal elements are the basic, indivisible syntactic constructs. They represent either a 
basic function in the functional syntax diagrams or a particular byte-encoding in the 
encoding syntax diagrams. 

All elements in the functional syntax diagrams are represented by an all upper-case 
description between brackets inside an oval. 
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EXAMPLE: 




<PROGRAM 
HEADER 
SEPARATOR> 




In the encoding syntax diagrams, terminal elements are directly defined as 8-bit data 
bytes or by reference to the ISO 7-bit Code Chart shown in figure 9-2. When a device 
receives ISO 7-bit characters, the sense of the eighth bit (DI08) shall be ignored. 

EXAMPLE: A space is represented by the following: 



-*G^ 



7.2.2.2 Non-terminal syntactic elements 

Non-terminal elements are intermediate syntactic constructs presented for clarity or 
emphasis. Non-terminals are presented in boxes to distinguish them from terminals. A 
non-terminal is always expandable to a diagram of terminal elements or (for encoding 
syntax) is explainable in a statement relating the element to a particular code set. Below 
the element name is a clause reference to the expansion diagram's location. 



EXAMPLE: 



<NON-TERMINAL 
SYNTACTIC ELEMENT> 
figure 7-0 



or 



<non-ierminal encoding 
syntactic mnemonio 
7.0.0 
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In the notation, functional elements are written in upper case and encoding elements are 
written in lower case between brackets unless a particular ISO 7-bit code is indicated. 



7.2.2.3 Rules 

Several encoding syntax diagrams require additional text to explain restrictions not easily 
shown in the diagram. These restrictions are included in a "Rules" section immediately 
following the diagram. 



7.2.3 Special symbols 

7.2.3.1 Upper/lower case equivalence 

To improve presentation, a special notation is used to indicate either upper-or lower-case 
alternative representation. This representation is indicated by enclosing in a circle the 
upper-case ISO 7-bit alpha symbol, a vertical bar, and the lower-case ISO 7-bit alpha 
symbol. 

EXAMPLE 




is equivalent to 



-h£h 




A END 



7.2.3.2 END message 

An oval containing MA END" indicates concurrent transmission of the END message with the 
preceding data byte. This symbol has no exit path as it always represents the end of a 
message. 

EXAMPLE: 




represents sending NL (newline) with EOI set TRUE and ATN FALSE. In text this is shown as NL*END. 
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z.2.3.3 Beginning of message 

The beginning of a message is indicated by a circle with no entry from the left. 

7.2.3.4 Diagram expansion 

Leading and trailing arrows indicate that the diagram represents an expansion to a 
detailed view of a portion of a higher level diagram. 

7.3 Terminated program messages - Functional syntax 
7.3.1 Function 

Terminated program messages are complete 'controller-to-device' messages. They are 
sequences of zero or more <PROGRAM MESSAGE UNIT> elements. The <PROGRAM 
MESSAGE UNIT> element represents a programming command or data sent to the device 
from the controller. The terminated message represents a "complete" transmission and, as 
such, has certain additional semantic meanings, see 7.5. 



7.3.2 Syntax 

The command's functional syntax shall match the following set of six diagrams in 
figures 7-1 to 7-6. 

NOTE - The use of the indefinite form of the <ARBITRARY BLOCK PROGRAM DATA> element, 
see 7.7.6, forces an immediate termination of the <PROGRAM MESSAGE>. 



a 



"X 



<PROGRAM MESSAGE> 
(figure 7-2) 




Figure 7-1 - TERMINATED PROGRAM MESSAGE> functional element syntax 
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X. 



X 




<PROGRAM MESSAGE 
UNIT> 
(figure 7-3) 



.Z 



Figure 7-2 - <PROGRAM MESSAGE> functional element syntax 




<COMMAND MESSAGE 
UNIT> 
(figure 7-4) 



<QUERY MESSAGE 

UNIT> 

(figure 7-5) 



Figure 7-3 - <PROGRAM MESSAGE UNIT> functional element syntax 



<COMMAND \ 


S <PROGRAM 


PROGRAM \ 


^J HEADER 


HEADER> / \ 


^ SEPARATOR> 


7.6.1 / 


N. 7.4.3 




cPROGRAM 0ATA> 
(figure 7-6) 



J_ 



T 



Figure 7-4 - -cCOMMAND MESSAGE UNIT> functional element syntax 
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<PROGRAM DATA> 
(figure 7-6} 



.z 



T 



Figure 7-5 - <QUEftY MESSAGE UNIT> functional element syntax 
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NOTE - <ARBITRARY BLOCK PROGRAM DATA> using the indefinite format ends with an implicit 
message terminator. In this case the message terminates with no exit. See 7.7.6. 



Figure 7-6 - <PROGRAM DATA> functional element syntax 
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7.3.3 Functional element summary 



Element 

<PROGRAM MESSAGE> 
figure 7-2 

<PROGRAM MESSAGE 
UNlT> figure 7-3 



Function 

Represents a sequence of zero or more <PROGRAM 
MESSAGE UNIT> elements separated by <PROGRAM 
MESSAGE UNIT SEPARATOR> elements. 

Represents a single command, programming data, or query 
received by the device. 



<COMMAND MESSAGE Represents a single command or programming data 

UNIT> figure 7-4 received by the device. 



<QUERY MESSAGE 
UN IT> figure 7-5 



Represents a single query sent from the controller to the 
device. 



<PROGRAM DATA> 
figure 7-6 



Represents any of the six different program data types. 



<PROGRAM MESSAGE Separates the <PROGRAM MESSAGE UNIT> elements 

UNIT SEPARATOR> 7.4.1 from one another in a <PROGRAM MESSAGE> ' 



<PROGRAM DATA 
SEPARATOR> 7.4.2 



Separates sequential <PROGRAM DATA> elements that 
are related to the same header. 



<PROGRAM HEADER 
SEPARATOR> 7.4.3 



Separates the header from any associated <PROGRAM 
DATA>. 



<PROGRAM MESSAGE 
TERMINATORS 7:5 



Terminates a <PROGRAM MESSAGE>. 



<COMMAND PROGRAM 
HEADER> 7.6.1 



Specifies function or operation. Used with any associated 
<PROGRAM DATA> element(s). 



<QUERY PROGRAM 
HEADER> 7.6.2 



<CHARACTER 
PROGRAM DATA> 7.7.1 



Similar to <COMMAND PROGRAM HEADER> except a 
query indicator (?) shows that a response is expected from 
the device. 

A data type suitable for sending short mnemonic data, 
generally where a numeric data type is not suitable. 
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Element 

<DECIMAL NUMERIC 
PROGRAM DATA> 7.7.2 



Function 

A data type suitable for sending decimal integers or 
decimal fractions with or without exponents. 



<SUFFIX PROGRAM 
DATA> 7.7.3 



An optional field following <DECIMAL NUMERIC 
PROGRAM DATA> used to indicate associated multipliers 
and units. 



<NON-OECIMAL NUMERIC A data type suitable for sending integer numeric 
PROGRAM 0ATA> 7.7.4 representations in base 16, 8, or 2. Useful for data that is 

more easily interpreted when directly expressed in a 

non-decimal format. 



<STRING PROGRAM 
DATA> 7.7.6 



<ARBITRARY BLOCK 
PROGRAM DATA> 7.7.6 



A data type suitable for sending ISO 7-bit character 
strings where the content needs to be "hidden* (by 
delimiters). 

A data type suitable for sending blocks of arbitrary 8-bit 
information. 



EXPRESSION PROGRAM 
DATA> 7.7.7 



A data type suitable for sending data that is evaluated as 
one or more non-expression data elements before further 
parsing. 



7.4 Separator functional elements 

7.4.1 <PROGRAM MESSAGE UNIT SEPARATOR 

7.4.1.1 Function 

The <PROGRAM MESSAGE UNIT SEPARATOR> separates sequential <PROGRAM 
MESSAGE UNIT> elements from one another within a <PROGRAM MESSAGE>. 

7.4.1.2 Encoding syntax 

A <PROGRAM MESSAGE UNIT SEPARATOR> is defined as 
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X. 



<white space 

character* 

7.4.1.2 



Where <white-space character is defined as a single ISO 7-bit encoded byte in the 
range 00-09, OB - 20 (0-9, 11-32 decimal). This range includes the ISO 7-bit control 
characters and the space but excludes the newline. 

7.4.1 .3 Semantic equivalence 

A device shall process <white'space> without semantic interpretation. 

A device shall interpret the semicolon (;) as the <PROGRAM MESSAGE UNIT 
SEPARATOR^ No alternative encodings are allowed. 

7.4.2 <PROGRAM DATA SEPARATOR 

7.4.2.1 Function 

The <PROGRAM DATA SEPARATOR> separates sequential <PROGRAM DATA> 
elements from one another after a <COMMAND PROGRAM HEADER> or <QUERY 
PROGRAM HEADER>. It is used when a <COMMAND PROGRAM HEADER> or <QUERY 
PROGRAM HEADER> has multiple parameters. 



7.4.2.2 Encoding syntax 

A <PROGRAM DATA SEPARATOR> is defined as 



X 



<white 
space> 
7.4.1.2 



T 



Qy^ 



<white 
space> 
7.4.1.2 



T 



Where <white space> is defined in 7.4.1.2. 

7.4.2.3 Semantic equivalence 

A device shall process <white space> without semantic interpretation. 

A device shall interpret the comma (,) as the <PROGRAM DATA SEPARATOR^ No 
alternative encodings are allowed. 
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7.4.3 <PROC ~>AM HEADER SEPARATOR> 

7.4.3.1 Function 

The <PROGRAM HEADER SEPARATOR> separates the <COMMAND PROGRAM 
HEADER> or <QUERY PROGRAM HEADER> from the <PROGRAM DATA> elements. 

7.4.3.2 Encoding syntax 

A <PROGRAM HEADER SEPARATOR> is defined as 




Where <white space> is defined in clause 7.4.1.2. 

7.4.3.3 Semantic equivalence 

A device shall interpret the first <white-space character as the <PROGRAM HEADER 
SEPARATOR>. No alternative encodings are allowed. 

Any additional <white-space> shall have no syntactic nor semantic value. 

7.5 <PROGRAM MESSAGE TERMINATOR> 

7.5.1 Function 

A <PROGRAM MESSAGE TERMINATOR> terminates a sequence of one or more definite 
length <PROGRAM MESSAGE UNIT> elements. A <PROGRAM MESSAGE TERMINATOR> 
is abbreviated in this standard as <PMT>. 



The terminator conveys additional semantic meaning with regard to the execution order of 
interactive or "coupled" commands, see 6.4.5.3, to the operation of the Output Queue, 
see 6.1.10, and to the syntactic use of compound headers, see 7.6.1.5 and 7.6.2.5. 
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7.5.2 Encoding syntax 

A <PROGRAM MESSAGE TERMINATOR> is defined as 




Where <white space> is defined in 7.4.1 .2. 

Where NL is defined as a single ISO 7-bit encoded byte OA (10 decimal). 

7.5.3 Semantic equivalence 

A device shall process <white space> without semantic interpretation. 

A device shall interpret any and all of the. three terminators (that is: END message on last 
data byte, newline with END message, or newline) as semantically equivalent. No 
alternative encodings are allowed. 

7.6 Program Header functional elements 

7.6.1 <COMMAND PROGRAM HEADER> 

7.6.1.1 Function 

The <COMMAND PROGRAM HEADER> represents the operation to be performed in a 
device. This element may be optionally followed by associated parameters encoded as 
<PROGRAM DATA> elements, See 7.7. 

Note that a macro label (see *DMC, see 10.7) may have the form of a <COMMAND 
PROGRAM HEADER> but may label a sequence of <PROGRAM MESSAGE UNIT> 
elements that contains valid <QUERY PROGRAM HEADER> elements (see 7.6.2.1) and 
thus would generate a response when processed. The *TRG common command 
(see 10.37) may also>be specified to generate $ response, 



A <compound command program header> allows for internal structure in the header. This 
structure is generally used by more complex devices to limit the number of unique headers 
and also to organize logically the device command set. 
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<compound command program header> elements are useful for handling hierarchically 
related command structures. <compound command program header> elements can 
provide shorthand mnemonic notation when used within a <PROGRAM MESSAGE> 
containing several <PROGRAM MESSAGE UNIT> elements. 



7.6.1 .2 Encoding syntax 

A <COMMAND PROGRAM HEADER> is defined as 





<whtte 
spaoe> 
7.4.1.2 






<sknple command 

program headeo 

7.6.1.2 






v 


r 1 




\ 




k 






















^compound command 

program hoador> 

7.6.1.2 






\ 
















^common command 

program haader> 

7.6.1.2 


^ m 











Where <white space> is defined in 7.4.1.2. 

Where <simple command program headeo is defined as 




Where <compound command program header> is defined as 




80 



IS 10767 (Part 2): 2001 
IEC 60625-2 (1993) 



Where <common command program header> is defined as 




•cprogram 

mnemonio 

7.6.1.2 



Where <program mnemonio is defined as 



<upper/lower 
casealpha> 
7.6.1.2 




Where <upper/lower-case alpha> is defined as a single ISO 7-bit encoded byte in the 
range 41 - 5A, 61 - 7A (65-90, 97-122 decimal). 

Where <digit> is defined as a single ISO 7-bit encoded byte in the range 30 - 39 (48 - 57 
decimal). 

Where (J represents an "underscore", a single ISO 7-bit encoded byte with the value 5F 
(95 decimal). 

7.6.1.3 Semantic equivalence 

A device shall interpret <upper/lower-case alpha> contained within the <program 
mnemonio without attaching semantic meaning to the case of the alpha characters. 



A device shall interpret the colon (:) as the <program mnemonio separator in the 
<compound command program header> element. No alternative encodings are allowed. 



A device shall process <white space> contained within a <COMMAND PROGRAM 
HEADER> without semantic interpretation. 
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7.6.1.4 Rules 

7.6.1.4.1 Length 

The <program mnemonio shall have a maximum length of 12 characters with a preferred 
length of four characters. 

7.6.1.4.2 <COMMAND PROGRAM HEADER> naming guidelines 

The relation of a <COMMAND PROGRAM HEADER> mnemonic and its associated 
function shall be readily apparent. These mnemonics shall be independent of control 
location on the front panel but shall relate to front panel or display nomenclature as 
appropriate. 

7.6.1 .4.3 <common command program header> rules 

The <common command program header> syntax is reserved for use by this standard and 
future revisions of this standard. Defined common commands and queries using this 
syntax are discussed in clause 10. 

Device designers shall not use the <common command program header> defined in 
clause 10 for purposes other than those defined in clause 10. 

7.6.1 .5 Header compounding rules 

That part of a <compound command program header> that excludes the trailing <program 
mnemonio element is defined as the "header-path". A <compound command program 
header> or <simple command program header> shall be interpreted by a device as if the 
header-path in the immediately preceding <compound command program header> or 
<compound query program header>, was sent immediately preceding that <compound 
command program header> or <simple command program header>. The supplied header-path 
shall include both any header-path explicitly stated in the immediately preceding command 
and any header-path supplied to the immediately preceding command by a previous 
application of the rule. 



This rule shall NOT be applied to: 

1) A <compound command program header> that begins a <PROGRAM MESSAGE>. 

2) A <compound command program header> that begins with a colon {:). 

The presence of a <common command program header> or <common query program 
header> has no effect on the header-path. 

See annex A for examples. 
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7.6.2 <QUERY PROGRAM HEADER> 

7.6.2.1 Function 

The <QUERY PROGRAM HEADER> represents the operation to be performed in a 
device. A <QUERY PROGRAM HEADER> causes the device to generate a response. 
This element may be optionally followed by associated parameters encoded as 
<PROGRAM DATA> elements, 7.7. 

Note that a macro label (see *DMC, 10.7) may have the form of a <QUERY PROGRAM 
HEADER> but may label a sequence of <PROGRAM MESSAGE UNIT> elements that 
contains no valid <QUERY PROGRAM HEADER> elements and thus would generate no 
response when processed. 



The <compound query program header> represents the function to be performed in 
conjunction with possible following data elements to form a program command. A 
<compound query program header> allows for internal structure in the header. 



This structure is generally used by more complex devices to limit the number of unique 
headers and also to organize logically the device command set for easier control and more 
readable code. <compound query program header> elements are useful for handling 
command structures that are hierarchically related. <com pound query program header> 
elements are capable of providing a shorthand mnemonic notation when used within 
multi-message-unit <PROGRAM MESSAGE> elements. 



7.6.2.2 Encoding syntax 

A <QUERY PROGRAM HEADER> is defined as 







<whit© 
space> 
7.4.1.2 










<simple query 

program header> 

7.6.2.2 






\ 


\ 


_y 


/ 


\ 




\ 




















<compound query 

program headeo 

7.6.2.2 






\ 
















<common query 

program header> 

7.6.2.2 


s . 











Where <white space> is defined in 7.4.1.2. 
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Where <simple query program header> is defined as 




Where <compound query program header> is defined as 




<program 

mnemonio 

7.6.1.2 




<program 

mnemonio 

7.6.1.2 




Where <common query program header> is defined as 




Where <program mnemonio is defined in 7.6.1.2. 

7.6.2.3 Semantic equivalence 

Semantic equivalence rules for <QUERY PROGRAM HEADER> are the same as for 
<COMMAND PROGRAM HEADER>, see 7.6.1.3. 



A device shall process <white space> contained within a <COMMAND PROGRAM 
HEADER> or <QUERY PROGRAM HEADER> without semantic interpretation. 



7.6.2.4 Rules 

General rules for <QUERY PROGRAM HEADER> are the same as for <COMMAND 
PROGRAM HEADER>. see 7.6.1.4. 
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7.6.2.5 Header compounding rules 



Rules for <compound query program headers> are the same as the rules for <compound 
command program headers>, see 7.6.1.5. 



See annex A for examples. 

7.7 <PROGRAM DATA> functional elements 

A <PROGRAM DATA> functional element is used to convey a variety of types of 
parameter information related to the program header. 

7.7. 1 <CHARACTER PROGRAM DA TA> 

7.7.1.1 Function 

The <CHARACTER PROGRAM DATA> functional element is used to convey parameter 
information best expressed mnemonically as a short alpha or alphanumeric string. It is 
useful in those cases where numeric parameters are inappropriate. 

7.7.1 .2 Encoding syntax 

A <CHARACTER PROGRAM DATA> element is defined as 



<program 

mnemonio 

7.6.1.2 



Where <program mnemonio is defined in 7.6.1 .2. 

7.7.1.3 Semantic equivalence 

The <program mnemonio as used in the <CHARACTER PROGRAM DATA> functional 
element shall follow the same semantic equivalence rules as when it is used in 
<COMMAND PROGRAM HEADER> element, see 7.6.1.3. 

7.7.1.4 Rules 

The <program mnemonio as used in the <CHARACTER PROGRAM DATA> functional 
element shall follow the same general rules as when it is used in the <COMMAND 
PROGRAM HEADER> element, see 7.6.1.4. 
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7.7.2 <DECIMAL NUMERIC PROGRAM DATA> 

7.7.2.1 Function 

The <DECIMAL NUMERIC PROGRAM DATA> is a flexible version of the three numeric 
representations (NR1* 2 and 3) as defined in ISO 6093. 

This element is also denoted by NRf (flexible numeric representation) in subsequent 
sections. 

7.7.2.2 Encoding syntax 

A <DECIMAL NUMERIC PROGRAM DATA> element is defined as 



<mantissa> 
7.7.2.2 



<white 



T— - spaoe> — j — ^- 7.7 j 



Where <mantissa> is defined as 




Where <digit> is defined in 7.6.1.2. 
Where <optional digits>MS defined as 
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Where <exponent> is defined as 




Where <digit> is defined in 7.6.1.2. 
Where <white space> is defined in 7.4.1.2. 

7.7.2.3 Semantic equivalence 

A device shall process <white space> without semantic interpretation. 

A device shall interpret all other ISO 7-bit encoded characters as comprising a decimal 
numeric format generally following any of the NR1, NR2 and NR3 formats of ISO 6093 as 
allowed by the diagram in 7.7.2.2. The interpreted value shall be subject to the rounding 
rule as stated in 7.7.2.4.2. 

7.7.2.4 Rules 

7.7.2.4.1 Range 

The mantissa of a <DECIMAL NUMERIC PROGRAM DATA> element shall contain no 
more than 255 characters excluding any leading zeros. 



<DECIMAL NUMERIC PROGRAM DATA> elements shall have an exponent value in the 
range -32000 through +32000. 

If the <DECIMAL NUMERIC PROGRAM DATA> element violates either of these rules, a 
Command Error shall be generated. 

7.7.2.4.2 Numeric element rounding 

A device may receive a <DECIMAL NUMERIC PROGRAM DATA> element which has 
greater precision than the device can handle internally. In this case, the device shall 
round off the number, not truncate the number, before interpretation. When rounding off, 
the device shall ignore the sign of the number and round up on values greater than or 
equal to exact half values. Values less than exact half values shall be rounded down. 



7.7.2.4.3 Error reporting 

Any error conditions reported shall be based on the result of the interpreted value after 
rounding. 
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7.7.2.4.4 Numeric out-of-range guidelines 

If a <DECIMAL NUMERIC PROGRAM DATA> element's value is outside the range 
allowed for the associated header, an Execution Error shall be reported. 



7.7.3 <SUFFIX PROGRAM DATA> 
7.7.3.1 Function 

A <SUFFIX PROGRAM DATA> element permits the use of a suffix following the 
<DECIMAL NUMERIC PROGRAM DATA> (NRf). The suffix expresses associated units 
and (optional) multipliers that modify how the NRf is interpreted by the device. 



As shown in the functional syntax in figure 7-6, the presence of a <SUFFIX PROGRAM 
DATA> after an NRf is always optional. No particular <COMMAND PROGRAM HEADER> 
or <QUERY PROGRAM HEADER> in a device shall require the use of a <SUFFIX 
PROGRAM DATA> element. 



7.7.3.2 Encoding syntax 

A <SUFFIX PROGRAM DATA> element is defined as 




Where <digit> is defined in 7.6.1 .2. 

Where <suffix mult.>, suffix multiplier, is defined as a sequence of one, two, or three 
<upper/lower-case alpha> characters. 

Where <suffix unit> is defined as a sequence of one to four <upper/lower-case alpha> 
characters. 

<upper/lower case-alpha> is defined in 7.6.1.2. 
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7.7.3.3 Semantic equivalence 

A device shall process <white space> without semantic interpretation. 

A device shall interpret all alpha characters with upper/lower-case semantic equivalence. 



All other ISO 7-bit encoded bytes in this functional element may or may not have semantic 
equivalence at the discretion of the device designer. 

The bypass within the <SUFFIX PROGRAM DATA> element shall be interpreted by the 
device as if a default <suffix multiplier and <suffix unit> had been received. This default 
suffix is specified by the device designer. 



7.7.3.4 Rules 

If a device uses suffixes, it should make use of the <suffix multiplier and <suffix unit> 
elements defined in this clause. Guidelines presented here for the use of <SUFFIX 
PROGRAM DATA> elements, have been defined in ISO 2955 and have been expanded to 
include non-SI derived units. 



Any <SUFFIX PROGRAM DATA> element not specifically listed in this standard shall 
contain mnemonic value to assist the user in relating the associated conversion to the 
suffix. 

Numeric rounding may be done before or after the conversion algorithm is applied. 

A <SUFFIX PROGRAM DATA> element shall contain no more than 12 characters, 
excluding the leading <white space>. 

7.7.3.4.1 <suffix unit> selection 

Table 7-1 presents some of the most common <suffix unit> elements used in devices 
along with several preferred and allowed secondary <suffix unit> elements for a variety of 
applications. 

<suff«x unit> elements should use the 'primary unit' mnemonics from table 7-1. Alternate 
<suffix unit> elements, however, are included in table 7-1 as 'secondary units' for use by 
the casual user who tends to think in measurement units. If a unit is not specified, the 
referenced standards should be consulted. 



The use of •E<digit>" or "E-<digit>" as a <SUFFIX PROGRAM DATA> element or as the 
leading characters of a <SUFFIX PROGRAM DATA> element is specifically disallowed 
because of possible confusion with the exponent of the preceding NRf. 
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TABLE 7-1 - <suffix unit> elements 





Preferred suffix 


Allowed suffix 




Class 






Referenced unit 




(primary unit) 


(secondary unit) 




Current 


A 




Ampere 


Pressure 


ATM 




Atmosphere 


Charge 


e 




Coulomb 


Illumination 


CD 




Candela 


Ratio 


DB (see 7.7.3.4.2) 




Decibel 


Power 


DBM 




Decibel milliwatt 


Capacitance 


F 




Farad 


Mass 


f 


G 


Gram (kilogram is the SI unit for 
compound units) 


Inductance 


H 




Henry 


Frequency 


HZ 




Hertz 


Pressure 


INHQ 




Inches of mercury 


Energy 


J 




Joule 


Temperature 


K 




Degree Kelvin 






CEL 


Degree Celsius 






FAR 


Degree Fahrenheit 


Volume 


L 




Litre 


Illumination 


LM 




Lumen 


Illumination 


LX 




Lux 


Length 


M 




Metre 






FT 


Foot 






IN 


Inch 


Frequency 




MHZ 


Megahertz 


Resistance 




MOHM 


Megohm 


Force 


N 




Newton 


Resistance 


OHM 




Ohm 


Pressure 


PAL 




Pascal 


Ratio 


PCT 




Percent 


Angle 


RAD 




Radian 






DEG 


Degree 






MNT 


Minute (of arc) 






SEC 


Second 


Time 


S 




Second 


Conductance 


SIE 




Siemens 


Mag density 


T 




Tesla 


Pressure 


TORR 




Torr 


Amplitude 


V 




Volt 


Power 


W 




Watt 


Mag flux 


WB 




Weber 


Luminous flux 


LM 




Lumen 



7.7.3.4.2 DB referencing 

To reference a relative unit (dB) to an absolute level, the absolute level is appended to the 
DB according to the following syntax. 
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Thus, decibels referenced to 1 milliwatt become DBMW. For historical reasons, DBM is 
allowed as an alias for DBMW. 

EXAMPLE: 

DBUW means DB referenced to 1 microwatt 

DBUV means DB referenced to 1 microvolt 

NOTE - A search of common practice shows that the form proposed here is the common usage and does 
not introduce ambiguity. 

7.7.3.4.3 <suffix mult.> selection rules 

The <suffix mult.> is used to modify the value of the <suffix unit>. The <suffix mult.> 
allows the user to enter values in common measurement units. Thus in some applications 
1 KHZ is preferable to 1 E3 HZ. Table 7-2 lists the allowed <suffix mult.>'s. 



NOTE - Only engineering unit multipliers are allowed. 

TABLE 7-2 - Allowed <suffix mult.> mnemonics 



Definition 


Mnemonic 


1E18 


EX 


1E1S 


PE 


1E12 


T 


1E9 


G 


1E6 


MA (see note) 


1E3 


K 


1E-3 


M (see note) 


1E-6 


U 


1E-9 


N 


1E-12 


P 


1E-15 


F 


1E-18 


A 



NOTE • The suffix units, MHZ and MOHM, are special cases which should not be confused with <suffix 
mult.>HZ or <suffix mult.>OHM. These special case <suffix units> are included in table 7-1 because of 
accepted industry practice. 

7.7.3.4.4 Use of units made up of combinations of SI rules 

When a need arises for complex units (i.e. newton-meter or meter per second), the 
following rules should apply. When the complex unit is the quotient of two units, then the 
character 7" should be used to separate the units. Thus M/S is the allowed representation 
for metre/second. 
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When the complex unit is the product of two units, the character "." should be used to 
separate the units. Thus N.M is the allowed representation for newton-metre. 

Suffix exponents are represented by a <digit>. They are used for units which appear more 
than once in a complex unit. When a suffix exponent is used, it should appear as a <digit> 
and be appended to the unit without a space. An example is the SI unit of acceleration, 
metres per second squared, written as M/S2. 

7.7.4 <NON-DECIMAL NUMERIC PROGRAM DA TA> 

7.7.4.1 Function 

The <NON-DECIMAL NUMERIC PROGRAM DATA> element allows passing numeric 
information in bases other than 10. These formats facilitate direct interpretation by system 
users and application programs for those applications where non-decimal numbers have 
direct significance. The use of this format may simplify conversion routines in application 
software. 
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7.7.4.2 Encoding syntax 

A <NON-DECIMAL NUMERIC PROGRAM DATA> element is defined as 



s*~@- 



\ 



< 






■y 



—CM 



^H® 



>■ 






/ 



J 



y 



\_ <digit> 
^ 7.6.1.2 




Where <digit> is defined in 7.6.1.2. 
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7.7.4.3 Semantic equivalence 

A device shall interpret any and all of the three specified non-decimal numeric formats as 
semantically equivalent numeric values. 

A device shall interpret <upper/lower-case alpha> without attaching semantic meaning to 
the case of the alpha characters. 

7.7.4.4 Rules 

7.7.4.4.1 Hexadecimal encoding 

The characters following a #H or #h preamble shall be interpreted as an unsigned implicit 
radix point hexadecimal number. 

The radix for hexadecimal numbers is 16. The decimal values and related ISO 7-bit code 
representations are as follows: 

Decimal value: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
ISO 7-bit code: 1 2 3 4 .5 6 7 8 9 A B CDEF 



Alternate 

ISO 7-bit Code: 0123456789a b cdef 

Non-hex characters shall generate a Command Error. 

7.7.4.4.2 Octal encoding 

The characters following a #Q or #q preamble shall be interpreted as an unsigned implicit 
radix point octal number. 

The radix for octal numbers is 8. The decimal values and reiated ISO 7-bit code 
representations are as follows: 

Decimal value: 12 3 4 5 6 7 
ISO 7-bit code: 12 3 4 5 6 7 

Non-octal characters shall generate a Command Error. 

7.7.4.4.3 Binary encoding 

The characters following a #B or #b preamble shall be interpreted as an unsigned implicit 
radix point binary number. 

The radix for binary numbers is 2. The decimal values and related ISO 7-bit code 
representations are as follows: 

Decimal value: 1 



ISO 7-bit code: 1 

Non-binary characters shall generate a Command Error. 
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7.7.5 <STRING PROGRAM DATA> 
7.7.5.1 Function 



The <STRING PROGRAM DATA> element allows any character In the ISO 7-bit code 
(including non-printable characters) to be transmitted as a message. This data field is 
particularly useful where text is to be displayed (for example, on a printer or CRT type 
device). The <STRING PROGRAM DATA> permits the use of format effectors, such as 
carriage return, newline, or space, to format text correctly. 



7.7.5.2 Encoding syntax 

A <STRING PROGRAM DATA> element is defined as 



rO 



"\ 



X. 



-< 



HD- 



X 



X. 




dnserted "> 
7.7.5.2 



<non-single 

quote char> 

7.7.5.2 




insertion "> 
7.7.5.2 



<non-double 
quote char> 
7.7.5.2 




>- 




Where <inserted '> is defined as a single ISO 7-bit character with the value 27 (39 
decimal). 
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Where <non-single quote char> is defined as a single ISO 7-bit character of any value 
except 27 (39 decimal). 

Where <inserted "> is defined as a single ISO 7-bit character with the value 22 (34 
decimal). 

Where <non-double quote char> is defined as a single ISO 7-bit character of any value 
except 22 (34 decimal). 

7.7.5.3 Semantic equivalence 

A device shall interpret string data encapsulated in either of the two specified delimited- 
string formats (that is, the use of double quotes or single quotes) as semantically 
equivalent. 

7.7.5.4 Rules 

7.7.5.4.1 Single quote delimiting 

A single quote (') followed directly by an <inserted > is used to represent a single ' within 
a <STRING PROGRAM DATA> delimited by single quotes. 



7.7.5.4.2 Double quote delimiting 

A double quote (") followed directly by an <inserted"> is used to represent a single" within 
a <STRING PROGRAM DATA> delimited by double quotes. 



7.7.6 <ARBITRARY BLOCK PROGRAM DA TA> 

7.7.6.1 Function 

The <ARBITRARY BLOCK PROGRAM DATA> element allows any 8-bit bytes (including 
extended ISO 7-bit codes) to be transmitted in a message. This element is particularly 
useful for sending large quantities of data. 



This element represents a general purpose solution to the transmission of 8-bit binary 
data. Specific binary coding is described in 9.2. 
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7.7.6.2 Encoding syntax 

An <ARBITRARY BLOCK PROGRAM DATA> element is defined as 



<nen-zero 
digit> 
7.7.6.2 





iL 



<digit> 
7.6.1.2 



<8-bit 
data byte> 
7.7.6.2 




"j 



<8-bit 
data byte> 
7.7.6.2 




NL 



END 



Where <digit> is defined in 7.6.1.2. 

Where <non-zero digit> is defined as a single ISO 7-bit encoded byte in the range 31-39 
(49-57 decimal). 

Where <8-bit byte> is defined* as an 8-bit byte in the range 00 - FF (0 - 255 decimal). 

NOTE - The use of the indefinite format (#0) requires NL A ENO and forces immediate termination of the 
<PROGRAM MESSAGE>. 

7.7.6.3 Semantic equivalence 

A device shall interpret <8-bit data bytes> in either of the two specified formats (that is, 
with #<non-zero digit> or #0 with the NL A END message termination) as semantically 
equivalent. 

7.7.6.4 Rules 

The value of the <non-zero digit> element shall equal the number of <digit> elements 
which follow. The value of the <digit> elements taken together as a decimal integer shall 
equal the number of <8-bit data byte> elements which follow. If the IEC 625-1 END 
message is received before the specified number of bytes has been received, a Command 
Error shall be reported. 

7.7.6.5 Notes and examples 

Designers should consider the implications of buffer size and availability, particularly in 
the intended receiving devices. The designer should not assume that all devices will be 
capable of accepting lengthy messages. See 4.9 for device specification requirements. 



The indefinite format is useful when the length of the transmission is not known or when 
transmission speed or other considerations prevents segmentation into definite length 
blocks. 
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For example, four data bytes (DAB's) may be sent using: 

1) #14<DABxDAB><DABxDAB> 

2) #3004<DABxDABxDABxDAB> 

3) #0<DABxDABxDABxDAB> NL A END. 

7.7.7 <EXPRESSlON PROGRAM DATA> 

7.7.7.1 Function 

The <EXPRESSION PROGRAM DATA> element evaluates to a scalar, vector, matrix, or 
string value. It allows parameters to be manipulated by the device. 

7.7.7.2 Encoding syntax 

An EXPRESSION PROGRAM DATA> element is defined as 




Where <expression> is defined as a sequence: 

- of ISO 7-bit encoded data bytes in the range 20 to 7E (32 to 126 decimal) except 
the double quote, number sign, single quote, left parenthesis, right parenthesis, and 
semicolon (characters 22, 23, 27, 28, 29, and 3B hexadecimal or 34, 35, 39, 40, 41, 
and 59 decimal respectively), and/or 

- a device-defined set of the <PROGRAM DATA> elements described in clause 7.7 
except the indefinite form of the <ARBITRARY BLOCK PROGRAM DATA>. This allows 
the representation of nested expressions. 



7.7.7.3 Semantic equivalence 

A device shall interpret <upper/lower-case alpha> contained in the <expression> element 
without attaching semantic meaning to the case of the alpha characters. 



ISO 7-bit encoded bytes contained in the <expression> element may have other rules or 
conditions for semantic equivalence at the discretion of the device designer. 

7.7.7.4 Rules 

The <expression> semantics are completely device-dependent, but the device shall be 
able to transform the <expression> into the equivalent of one or more <PROGRAM DATA> 
elements that are not <expression> elements. 
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Devices may allow properly nested subexpressions within an <expression> up to a 
device-defined maximum nesting depth. A subexpression is a syntactically correct 
<expression> which is completely contained within an <expression>. 



The device documentation shall clearly indicate which <PROGRAM DATA> elements may 
appear within an <expression> as well as the maximum subexpression nesting depth. The 
device documentation shall clearly indicate any additional syntax restrictions which the 
device may place on the <expression>. 



The characters listed in 7.7.7.2 (double quote, number sign, single quote, left and right 
parentheses, and semicolon) may not appear within the body of the <expression> but may 
appear within a <STRING PROGRAM DATA> or <ARBITRARY BLOCK PROGRAM DATA> 
element in an <expression> or subexpression. 



8 Device talking formats 

8.1 Overview 

This clause discusses the formatting of <RESPONSE MESSAGE> elements sent from a 
device via its system Interface. As in clause 7, the formatting occurs on two levels, the 
functional and the encoding. The overview material for clause 7 applies here except that 
the codes are device, and not human, generated and thus embody a minimum amount of 
flexibility in the encoding syntax. For human readability and consistency, the encoding 
syntax is, in most cases, obtained from a subset of the controller-to-device syntax. 



Particular needs may require a device to talk directly, i.e. not through a controller, to a 
device or class of devices which do not understand the IEC 625-2 <RESPONSE 
MESSAGE> syntax. For example, a device may be able to calibrate itself by commanding 
a particular model source to supply a stimulus. A more common example might be a 
device which is able to use the bus to command a printer or plotter to print or graph 
internally stored data. All deviations from IEC 625-2 to achieve device-to-device message 
transfer, as described above, shall be minimized and shall be explicitly documented. 



8.2 Notation 

Syntax diagram notation follows the same format as is described in 7.2. 

8.3 Terminated response messages - Functional syntax 

8.3.1 Function 

A terminated <RESPONSE MESSAGE> is a *device-to-controller' message. It typically 
contains measurement results, settings, or status information. 
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A <RESPONSE MESSAGE> is interpreted by a controller running an application program, 
and as such, needs to convey its information precisely for consistent operation with a wide 
range of controllers. A <RESPONSE MESSAGE>, therefore, has a more restrictive format 
than a <PROGRAM MESSAGE>, see clause 7. 



8.3.2 Syntax 

The functional syntax of the device's response shall be generated by following the 
four-diagram set in figures 8-1 to 8-4. The use of either the <ARBITRARY ISO 7-bit 
RESPONSE DATA> element, see 8.7.11, or the INDEFINITE LENGTH ARBITRARY 
BLOCK RESPONSE DATA> element, see 8.7.10, forces an immediate termination of the 
<RESPONSE MESSAGE>. 



<RESPONSE MESSAGE> 
(figure 8-2) 




<RESPONSE MESSAGE 

TERMINATOR> 

8.5 




Figure 8-1 - TERMINATED RESPONSE MESSAGE> functional element syntax 




<RESPONSE 
MESSAGE UNIT> 
(figure 8-3) 



Figure 8-2 - <RESPONSE MESSAGE> functional element syntax 

The <RESPONSE MESSAGE UNIT> has two basic syntaxes. The first is a "precise" 
version of the <PROGRAM MESSAGE UNIT> syntax, and is generally used for returning 
setting information. The second is "headerless" and is typically used to return 
measurement results with a minimum of bus overhead. 
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Figure 8-3 - <RESPONSE MESSAGE UNlT> functional element syntax 
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CHARACTER 
RESPONSE DATA> 
8.7.1 



<NR1 NUMERIC 
RESPONSE DATA> 
8.7.2 



<NR2 NUMERIC 
RESPONSE DATA> 
8.7.3 



<NR3 NUMERIC 
RESPONSE DATA> 
8.7.4 



<HEXAOECIMAL 
NUMERIC RESPONSE 
DATA> 
8.7.5 



<OCTAL NUMERIC 

RESPONSE DATA> 

8.7.6 



<BINARY NUMERIC 

RESPONSE DATA> 

8.7.7 



<STRING 

RESPONSE DATA> 

8.7.8 



<DEFINITE LENGTH 
ARBITRARY BLOCK RESPONSE DATA> 
8.7.9 



INDEFINITE LENGTH 
ARBITRARY BLOCK RESPONSE DATA> 
8.7.10 (see note) 



ARBITRARY ISO 

RESPONSE 0ATA> 

8.7.11 (see note) 




Figure 8-4 - <RESPONSE DATA> functional element syntax 

NOTE • The <ARBITRARY ISO 7-bit RESPONSE DATA> and <INDEFINITE LENGTH ARBITRARY 
BLOCK RESPONSE DATA> elements end with an implied message terminator. In this case, the message 
terminates with no exit. 
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8.3.3 Functional element summary 
Element 



Function 



<RESPONSE MESSAGE> Represents a sequence of one or more <RESPONSE 
figure 8-2 MESSAGE UNIT> elements separated by <RESPONSE 

MESSAGE UNIT SEPARATOR> elements. 

Represents a single message unit sent from the device. 



<RESPONSE MESSAGE 
UNIT> figure 8-3 

<RESPONSE DATA> 
figure 8-4 



Represents one of the 11 defined <RESPONSE DATA> 
elements. 



<RESPONSE MESSAGE Separates <RESPONSE MESSAGE UNIT> elements from one 
UNIT SEPARATOR> 8.4.1 another in a <RESPONSE MESSAGE>. 



<RESPONSE DATA 
SEPARATOR> 8.4.2 

<RESPONSE HEADER 
SEPARATOR> 8.4.3 

<RESPONSE MESSAGE 
TERMINATOR> 8.5 



Separates sequential <RESPONSE DATA> elements that are 
related to the same header or to each other. 

Separates the header from the <RESPONSE DATA>. 



Terminates a <RESPONSE MESSAGE>. 



<RESPONSE HEADER> 
8.6 



Specifies the function of the associated <RESPONSE DATA> 
element(s). Alpha and numeric characters mnemonically indicate 
the function. Internal structure is provided for hierarchical 
header structuring. 



<CHARACTER RESPONSE A data type suitable for sending short mnemonic character 
DATA> 8.7.1 strings. Generally used when a numeric parameter is not suitable. 

<NR1 NUMERIC Suitable for sending implicit radix decimal values. 

RESPONSE DATA> 8.7.2 

<NR2 NUMERIC Suitable for sending explicit radix decimal values. 

RESPONSE DATA> 8.7.3 

<NR3 NUMERIC Suitable for sending explicit radix decimal values with an 

RESPONSE DATA> 8.7.4 exponent. 

<HEXADECIMAL NUMERIC Suitable for sending implicit radix hexadecimal values. 
RESPONSE DATA> 8.7.5 

<OCTAL NUMERIC Suitable for sending implicit radix octal values. 

RESPONSE DATA>8.7.6 

<BINARY NUMERIC Suitable for sending implicit radix binary values. 

RESPONSE DATA> 8.7.7 



103 



IS 10767 (Part 2): 2001 
I EC 60625-2 (1993) 



Element 

<STRING RESPONSE 
DATA> 8.7.8 



Function 

A data type suitable for sending ISO 7-bit character strings where 
the contents need to be "hidden" by delimiters. This element is 
generally used to send data for direct display on a device. 



<DEFINITE LENGTH 
ARBITRARY BLOCK 
RESPONSE DATA> 8.7.9 



A data type suitable for sending blocks of 8-bit binary 
information when the length is known beforehand. 



INDEFINITE LENGTH A data type suitable for sending blocks of 8-bit binary 

ARBITRARY BLOCK information when the length is not known beforehand or when 

RESPONSE DATA> 8.7.10 computing the length beforehand is undesirable. 

<ARBITRARY ISO 7-bit RE- Suitable for sending arbitrary ISO 7-bit codes when alternate 

SPONSE DATA> 8.7.1 1 data types are unworkable. 



8 . 4 Separator functional elements 

8.4.1 <RE$PONSE MESSAGE UNIT SEPARA TOR> 

8.4.1.1 Function 

The <RESPONSE MESSAGE UNIT SEPARATOR> separates sequential <RESPONSE 
MESSAGE UNIT> elements from one another when multiple <RESPONSE MESSAGE 
UNIT> elements are sent in a <RESPONSE MESSAGE>. 



8.4.1 .2 Encoding syntax 

A <RESPONSE MESSAGE UNIT SEPARATOR> is defined as 




8.4.2 <RESPONSE DA TA SEPARA TOR> 

8.4.2.1 Function 

The <RESPONSE DATA SEPARATOR> separates sequential <RESPONSE DATA> 
elements from one another when multiple data elements are sent. 
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8.4.2.2 Encoding syntax 

A <RESPONSE DATA SEPARATOR is defined as 




8.4.3 <RESPONSE HEADER SEPARATOR> 

8.4.3.1 Function 

The <RESPONSE HEADER SEPARATOR> unambiguously separates the <RESPONSE 
HEADER> from the <RESPONSE DATA>. 

8.4.3.2 Encoding syntax 

A <RESPONSE HEADER SEPARATOR> is defined as 




8.5 <RESPONSE MESSAGE TERMINATOR> 

8.5.1 Function 

The <RESPONSE MESSAGE TERMINATOR> element's function is to terminate a 
sequence of one or more <RESPONSE MESSAGE UNIT> elements. 

8.5.2 Encoding syntax 

A <RESPONSE MESSAGE TERMINATOR> is defined as 



-—0- 




END 



8.6 <RESPONSE HEADER> 
8.6.1 Function 

The <RESPONSE HEADER> is available for use by the device designer for 
device-specific responses. It may be used, for example, to create responses in directly 
resendable <PROGRAM MESSAGE UNIT> format or to identify response data to the 
controller. 
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8.6.2 Encoding syntax 

A <RESPONSE HEADER> is defined as 






<simple 
response 
header> 
8.6.2 



<compound 
response 

header> 

8.6.2 



<common 
response 
headeo 
8.6.2 



"\ 



A. 



Where <simple response mnemonio is defined as 



<response 
mnemonio 
8.6.2 



Where <compound response header> is defined as 




<response 
mnemonio 
8.6.2 




Where <common response header> is defined as 



z. 



<response 
mnemonio 
8.6.2 
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Where <response mnemonio is defined as 




Where <upper-case alpha> is defined as a single ISO 7-bit encoded byte in the range 
41 - 5A (65-90 decimal). 

Where <digit> is defined in 7.6.1.2. 

Where (_) represents an "underscore", a single ISO 7-bit encoded byte with the value 5F 
(95 decimal). 

8.6.3 Rules 

The <response mnemonio shall have a maximum length of 12 characters. 

The relation of a <response mnemonio and its related function shall be readily apparent. 



The semantics of <compound response mnemonio elements used in a <RESPONSE 
HEADER> is beyond the scope of this standard. 

<common response header> elements may only be used to represent <COMMAND 
PROGRAM HEADER> elements defined in clause 10. 



8.7 <RESPONSE DA TA> functional elements 

A <RESPONSE DATA> functional element conveys a variety of response information. The 
element type is determined by the eliciting query or query equivalent (e.g. macro 
expansion). 

8.7.1 <CHARACTER RESPONSE DATA> 
8.7.1.1 Function 

The <CHARACTER RESPONSE DATA> functional element is used to convey information 
best expressed mnemonically as a short alpha or alphanumeric string. It is useful when 
numeric parameters are inappropriate. 
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8.7.1 .2 Encoding syntax 

A <CHARACTER RESPONSE DATA> is defined as 



■cresponse 
mnemonio 
8.6.2 



Where <response mnemonio is defined in 8.6.2. 

8.7.1.3 Rules 

The <response mnemonio shall comply with the rules as stated in 7.6.1.4.1 to 7.6.1.4.3. 

8.7.2 <NR1 NUMERIC RESPONSE DATA> 

8.7.2.1 Function 

<NR1 NUMERIC RESPONSE DATA> elements consist of a set of implicit point 
representations of numeric values. That is, a radix point is implicitly considered to be 
placed (fixed but not transmitted) at the right end of the string of digits. 

8.7.2.2 Encoding syntax 

An <NR1 NUMERIC RESPONSE DATA> is defined as 




8.7.2.3 Rules 

8.7.2.3.1 Out-of-range 

Numeric representation of out-of-range information shall be sent with the same numeric 
data type as for in-range information with a value outside of the normal range of 
measurements. Also, the DDE bit shall be set in the Standard Event Status Register. 
See 11.5.1.1.6. 



108 



IS 10767 (Part 2): 2001 
IEC 60625-2 (1993) 

For example, a voltmeter with a maximum measurement capability of 100 V could indicate 
that it was measuring above 100 V by returning a response with a pre-defined "overrange" 
value above 100. This value shall be returned as <NR1 NUMERIC RESPONSE DATA> if 
the normal in-range responses are returned as <NR1 NUMERIC RESPONSE DATA> 
elements. 

8.7.2.3.2 Allowable range 

The allowable range for NRVs is the same as the range for double precision floating point 
numbers (+/- 179.76. . . E+306). See IEC 559 and clause 9 for details of floating point 
formats. 

8.7.3 <NR2 NUMERIC RESPONSE DATA> 

8.7.3.1 Function 

<NR2 NUMERIC RESPONSE DATA> elements are the representations of explicit point 
numeric values. 

8.7.3.2 Encoding syntax 

An <NR2 NUMERIC RESPONSE DATA> is defined as 




Where <digit> is defined in 7.6.1 .2. 

8.7.3.3 Rules 

The allowable range for NR2's is the same as the range for double precision floating point 
numbers (+/- 179.76. . . E+306). See IEC 559 and clause 9 for details of floating point 
formats. 

Out-of-range encoding rules are identical to those of 8.7.2.3. 

8.7.4 <NR3 NUMERIC RESPONSE DATA> 
8.7.4.1 Function 

<NR3 NUMERIC RESPONSE DATA> elements are representations of scaled explicit radix 
point numeric values together with an exponent notation. 



109 



IS 10767 (Part 2) : 2001 
I EC 60625-2 (1993) 

8.7.4.2 Encoding syntax 

An <NR3 NUMERIC RESPONSE DATA> is defined as 




Where <digit> is defined in 7.6.1.2. 

8.7.4.3 Rules 

The allowable range for NR3's is the same as the range for double precision floating point 
numbers (+/- 179.76. . . E+306). See IEC $59 and clause 9 for details of floating point 
formats. 

Out-of-range encoding rules are identical to those of 8.7.2.3. 

8.7.5 <HEXADECIMAL NUMERIC RESPONSE DA TA> 

8.7.5.1 Function 

The <HEXADECIMAL NUMERIC RESPONSE DATA> element is used to represent implicit 
radix, base 16 numeric information. 
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8.7.5.2 Encoding syntax 

A <HEXADECIMAL NUMERIC RESPONSE DATA> is defined as 




Where <digit> is defined in 7.6.1 .2. 
8.7.5.3 Rules 

The encoding rules are identical to those in 7.7.4.4.1, except that the alternate 
(lower-case) ISO 7-bit code option is disallowed. 

8.7.6 <OCTAL NUMERIC RESPONSE DATA> 
8.7.6.1 Function 

The <OCTAL NUMERIC RESPONSE DATA> element is used to represent base 8, implicit 
radix numeric information. 
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8.7.6.2 Encoding Syntax 

An <OCTAL NUMERIC RESPONSE DATA> is defined as 




8.7.6.3 Rules 

The encoding rules are identical to those in 7.7.4.4.2, except that the alternate 
(lower-case) ISO 7-bit code option is disallowed. 

8.7.7 <BINARY NUMERIC RESPONSE DATA> 

8.7.7.1 Function 

The <BINARY NUMERIC RESPONSE DATA> element is used to represent base 2, implicit 
radix numeric information. 
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8.7.7.2 Encoding syntax 

A <BINARY NUMERIC RESPONSE DATA> is defined as 




8.7.7.3 Rules 

The encoding rules are identical to those in clause 7.7.4.4.3, except that the alternate 
(lower-case) ISO 7-bit code option is disallowed. 

8.7.8 <STRING RESPONSE DATA> 

8.7.8.1 Function 

The <STRING RESPONSE DATA> elements allow any character in the ISO 7-bit code 
(including non-printable characters) to be transmitted as a part of a message. This data 
field is particularly useful when text is to be displayed (for example, on a printer or CRT 
type device). The <STRING RESPONSE DATA> element permits the use of format 
effectors such as carriage return, newline, or space to format text correctly. 
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8.7.8.2 Encoding syntax 

A <STRING RESPONSE DATA> is defined as 



— O 




inserted "> 
7.7.5.2 



X 



M 



>-4 



<non-double 
quote cftar> 
7.7.5.2 




Where <inserted "> is defined in 7.7.5.2. 

Where <non-double quote char> is defined in 7.7.5.2. 

8.7.8.3 Rules 

The encoding rules are the same as for <STRING PROGRAM DATA>, see 7.7.5.4. 

Bit 8 shall be set false when transmitting ISO 7-bit data. 

8.7.8.4 Notes and examples 

Alternate methods of encapsulating ISO 7-bit text/limited to response from a device, are 
the <ARBITRARY ISO 7-bit RESPONSE DATA> element, see 8.7.11, the <DEFINITE 
LENGTH ARBITRARY BLOCK RESPONSE DATA> element, see 8.7.9. and the 
<INDEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element, see 8.7.10. 
The last element should only be used if alternate formats are unworkable. 

8.7.9 <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> 

8.7.9.1 Function 

The <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element allows any 
type of device-dependent data to be transmitted over the system Interface as a series of 
8-bit data bytes. This element is particularly useful for sending large quantities of data, 
8-bit extended ISO 7-bit codes, or other data which are not directly displayable. 

Specific recommended binary encodings for use with this element are described in clause 9. 
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8.7.9.2 Encoding syntax 

A <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> is defined as 








/ 




) 




/ "■ ■ 




\ 




<norvzero 
<Hgit> 
7.7.6.2 






<digit> 
7.6.1.2 




\. 


<8-bit 
data byte> 
7.7.6.2 


/ 








\ 






/ • 








\ 






/ 



Where <non-zero digit> is defined in 7.7.6.2. 

Where <digit> is defined in 7.6.1.2. 

Where <8-bit data bytes> is defined in 7.7.6.2. 

8.7.9.3 Rules 

The rules are identical to those of 7.7.6.4. 

8.7.9.4 Notes and examples 

Device designers should consider the implications of buffer size and availability in the 
intended receiving controllers. Designers should not assume that all controllers will 
automatically be capable of accepting lengthy messages. See clause 14 for controller 
specification requirements. 

8.7.1 INDEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> 

8.7.10.1 Function 

The INDEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element is useful 
when transmitting 8-bit data bytes when the length of the transmission is not known or 
where transmission speed or other conditions prevent segmenting the output into known 
length blocks. 

The functional syntax diagrams permit the use of this element only as the final element in 
a TERMINATED RESPONSE MESSAGE> (see figure 8-4). 
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8.7.10.2 Encoding syntax 

An INDEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> is defined as 




Where <8-bit data byte> is defined in 7.7.6.2. 

NOTE - The IEC €25-1 END message serves the dual function of terminating this element as welt as 
terminating the <RESPONSE MESSAGE>. It is only sent once with the last byte of the indefinite block 
data. The NL is present for consistency with the <RESPONSE MESSAGE TERMINATOR>. 



8.7.10.3 Rules 

This format should only be used where other <RESPONSE DATA> element formats are 
unworkable. 

8.7.1 1 <ARBITRARY ISO 7-bit RESPONSE DATA> 

8.7.11.1 Function 

The <ARBITRARY ISO 7-bit RESPONSE DATA> element allows devices to respond with 
undelimited 1SO 7-bit text. In some cases this element facilitates controller handling of 
device information, such as displayed text. 

The functional syntax diagrams permit the use of this element only at the end of a 
TERMINATED RESPONSE MESSAGE> (see figure 8-4). 

8.7.11.2 Encoding syntax 

An <ARBITRARY ISO 7-bit RESPONSE DATA> is defined as 



"X 



^. 



<ISO 7-bit 
databyte> 
87.11.2 



JL 



T 




NL 



*END 



Where <ISO 7-bit data byte> represents any ISO 7-bit encoded data byte except NL (0A, 
10 decimal). 
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NOTES 



1 The END message provides an unambiguous termination to an element that contains arbitrary 
ISO 7-bit characters. 

2 The IEC 625-1 END message serves the dual function of terminating this element as well as 
terminating the <RESPONSE MESSAGE;* . It is only sent once with the last byte of the indefinite block 
data. The NL is present for consistency with the <RESPONSE MESSAGE TERMINATOR>. 



9 Message data coding 

This clause of IEC 625 specifies specific forms of coding for device-specific messages. 
The ISO 7-bit code is the code used throughout this document for the majority of the 
syntactic and semantic definitions. Eight-bit coding is allowed in special block message 
elements: <ARBITRARY BLOCK PROGRAM DATA>, see 7.7.6, <DEFINITE LENGTH 
ARBITRARY BLOCK RESPONSE DATA>, see 8.7.9, and INDEFINITE LENGTH 
ARBITRARY BLOCK RESPONSE DATA>, see 8.7.10. 



9.1 ISO 7-bit codes 

ISO 646 (1991) ISO 7-bit code is the common data representation code for communication 
of device-specific messages as described throughout clauses 7 and 8. 



The ISO 7-bit code bits shall be assigned to the DIO signal lines as shown in table 9-1, 
The ISO 7-bit code chart is shown in table 9-2. 

Table 9-1 - ISO 7-bit code/line relationship 



ISO 7-bit code: 


4* 


B7 


B6 


65 


B4 


B3 


B2 


B1 


DIO tine: 


DI08 


DI07 


D106 


DI05 


DI04 


DI03 


DI02 


DI01 


" Bit 8 (DI08) shall be sent FALSE and ignored on reception by devices. 



9.2 Binary 8-bit integer codes 

The following codes are the recommended formats for use with block program and 
response elements, see 7.7.6, 8.7.9, and 8.7.10. Although other codes are not prohibited 
by this standard, the use of the following codes is preferred. 



9.2.1 Byte order and data line relationships 

Bit binary codes utilize high and low bits to directly represent binary (radix 2) numbers. 
Each binary number is sent in a data field consisting of as many 8-bit bytes as desired. 
The contents of the data field shall be sent most significant byte first. 
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A typical data field is illustrated below. 
Sequence: |«- byte 1 -»| |<- byte 2 ->| 

87654321 87654321 

A A 

MSB (most significant LSB (least significant 

bit position) bit position) 

Binary codes shall be 1 , 2, 4 or 8 bytes wide. 
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Tabte 9-2 - ISO 7-bit code chart 



The dashed area corresponds to the range of codes defined as <white space>. 



B7 
B 


5 

B5 
S 

B2 B 


I 










1 



1 






1 
1 


1 




1 

1 


1 
1 



1 
1 
1 


BIT 
B4 B3 


CONTROL 


NUMBERS 
SYMBOLS 


UPPER CASE 


LOWER CASE 










NUL 

]o 


[20 
DLE 

10 16 


40 Oi 

SP I 

20. _ _32' 


60 16 


30 48 


100 
@ 

40 64 


120 16 

P 
50 80 


140 
60 96 


160 16 

P 
70 112 





1 


I 


,1 GTL 
i SOH 
'1 1 


21 LLO| 

DC1 i 

11 17" 


41 

! 
21 


1 
33 


61 17 

1 
31 49 


101 1 

A 

41 65 


121 17 

Q 
51 81 


141 1 

a 

61 97 


161 17 

q 

71 113 





1 


I 2 

i STX 

|2 2 


22 ; 
DC2 

12 ie. 


42 
22 


2 

34 


62 18 

2 
32 50 


102 2 
B 

42 66 


122 18 

R 

52 82 


142 2 

b 

62 98 


162 18 

r 

72 114 





1 1 


I 


>3 

' ETX 

•3 3 


23 i 

DC3 • 

13 19' 


43 

# 
23 


3 
35 


63 19 
3 

33 51 


103 3 

C 
43 67 


123 19 

S 

53 83 


143 3 

C 
63 99 


163 19 

S 
73 115 


1 





r* SDC 
. EOT 
•4 4 


24 DCLl 

DC4 i 

14 20 ( 


44 

$ 
24 


4 
36 


64 20 

4 
34 52 


104 4 

D 
44 68 


124 20 

T 

54 84 


144 4 

d 

64 100 


164 20 

t 
74 116 


1 


1 


I 


'5 PPC 

! ENQ 

!5 5 


25 PPU' 

NAK ' 

15 21] 


45 

% 
25 


5 
37 


65 21 

5 

35 53 


105 5 

E 

45 69 


125 21 

u 

55 85 


145 5 

e 

65 101 


165 21 

U 

75 117 


1 


1 


6 

' ACK 

« 6 


26 i 

SYN i 

16 22) 


46 

& 
26 


6 
38 


66 22 

6 
36 54 


106 6 

F 
46 70 


126 22 

V 
56 86 


146 6 

f 
66 102 


166 22 

V 
76 118 


1 


1 1 




1 BEL 
i7 7 


27 ; 

ETB 
17 23, 


47 

t 

27 


7 
39 


67 23 

7 
37 55 


107 7 

Q 

47 71 


127 23 

W 
57 87 


147 7 

g 

67 103 


167 23 

W 
77 119 


1 





HO GET 

1 BS 

*8 8 


30 SPEi 

CAN ' 

18 24> 


50 
28 


8 
40 


70 24 

8 
38 56 


110 8 

H 
48 72 


130 24 

X 

58 88 


150 8 

h 

68 104 


170 24 

X 
78 120 


1 





1 


!l1 TCT 
. HT 
|9 9 


31 spd! 

EM i 

19 25, 


51 


9 
41 


71 25 

9 

39 57 


111 9 

I 
49 73 


131 25 

Y 
59 89 


151 9 

i 

69 105 


171 25 

y 

79 121 


1 


1 


12" t 

LF ' 

,A_ _ _ jq! 


32 • 

SUB ; 

1A 26] 


52 

* 

2A 


10 
42 


72 26 
3A ' 58 


112 10 

J 
4A 74 


132 26 

z 

5A 90 


152 10 
6A 106 


172 26 

Z 
7A 122 


1 


1 


1 


,13 

i VT 
iB 11 


33 i 

ESC . 

1B 27i 


53 

+ 
2B 


11 
43 


73 27 
3B ' 59 


113 11 

K 
4B 75 


133 27 
5B 91 


153 11 

k 

6B 107 


173 27 
7B 123 


1 1 


( 


J 


'14 

JC 12 


34 ] 

FS 
1C 28] 


54 
2C ' 


12 

44 


74 28 
3C 60 


114 12 

L 
4C 76 


134 28 

\ 
5C 92 


154 12 

I 

60 108 


174 28 

I 
7C 124 


1 1 





1 


115 

' CR 

ID 13 


35 " 

GS ' 

1D 29' 


55 
2D 


13 
45 


75 29 
3D ~ 61 


"V 3 

4D 77 


135 29 
5D 93 


155 13 

m 

6D 109 


175 29 
7D 125 


1 1 


1 ( 


3 


;ig 
, so 

iE 14 


36 , 

RS i 

1E 30i 


56 
2E 


14 
46 


76 30 

> 
3E 62 


116 14 

N 
4E 78 


136 30 

A 

5E 94 


156 14 

n 

6E 110 


176 30 
7E 126 


1 1 


1 


1 


'17 

If is, 


37 ' 
US 

.if_ _ a\l 


57 

/ 
2F 


15 
47 


77 UNL 
? 

3F ' 63 


117 15 


4F 79 


137 UNT 

5F ~~ 95 


157 15 


6F 111 


177 DEL 
JRUBOUJ, 


KEY 






ADRS UNIV LISTEN TALK SECONDARY 
CMOS CMOS ADDRESSES ADDRESSES ADDRESSES 

OR COMMANDS 

IEC 625-1 code 
ISO 7-bit character 

decimal 


octal 
hex 


25 PPU 

NAK 
15 21 
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9.2.2 Binary integer code 

Binary integer is assumed to be right-justified in the data field, with the radix point to the 
right of the least significant bit position. 2's complement representation is assumed and 
the contents of the most significant bit position is interpreted as the sign bit. If the device 
data word is not as wide as the field, then the most significant (sign) bit shall be extended 
to fill the field. 



9.2.3 Binary unsigned integer code 

Binary unsigned integer is right-justified as described above. The contents of the data 
field's most significant bit is not interpreted as a sign, but as the most significant bit of a 
positive number. Thus any most-significant unused data bits in the data field should be 
zero filled. 

9.3 Binary floating point code 

The floating point representation included here is a subset of the IEC 559 on Floating 
Point Arithmetic. 

9.3.1 Floating point code fields 

Floating point numbers shall be represented by three fields. The fields are: 

1) The sign field 

2) The exponent field 

3) The fraction field 

The size of the fields depends on the precision of the number. 



For single precision numbers: 

Sign field width 1 bit 

Exponent field width 8 bits 

Fraction field width 23 bits 

Total width 32 bits 



E(max) 




+127 


E(min) 




-126 


Exponen 


it bias 


+127 



For double precision numbers: 

Sign field width 1 bit 

Exponent field width 1 1 bits 

Fraction field width 52 bits 

Total width 64 bits 



£(max) +1023 

£{min) -1022 

Exponent bias +1023 
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9.3.2 Basic formats 

Numbers in the single and double formats are composed of the following three fields: 

1) 1-bit sign s (s - = positive) (s - 1 - negative) 

2) Biased exponent e = E + bias 

3) Fraction / = .b(1)b(2). • &(p-1) 
where 

p is the number of significant bits 
b(n) = or 1 

The range of the unbiased exponent E shall include every integer between two values 
E(min) and E(max), inclusive, and also two other reserved values E(min)-1 to encode ±0 
and denormalized numbers, and E(max)+1 to encode ±~ and NaNs (Not a Number 
symbol). The foregoing parameters are given in 9.3.1. Each non-zero numerical value has 
just one encoding. The fields are interpreted as follows: 

9.3.2.1 Single 

A 32-bit single format number Xis divided as shown in 9.3.2. The value vof Xis inferred 
from its constituent fields, thus 

1) If e ~ 255 and f*Q, then vis NaNs regardless of 5 

2) If e=255andf=0, then v= (-1) s ~ 

3) If0<e<255, then v= (~1) s 2e~ 127 (1.r) 

4) lfe = 0and/*0, then v= (-1) s 2" 126 (0./) 
(denormalized numbers) 

5) If e - and / = 0, then v = (-1 ) s (zero) 

9.3.2.2 Double 

A 64-bit double format number X is divided as shown in clause 9.3.2. The value v of X is 
inferred from its constituent fields, thus 

1) If e = 2047 and f * 0, then v is NaNs regardless of s 

2) If e = 2047 and f = 0, thenv=(-1) s ~ 

3) If0<e<2047, then v= (_1) s 2 e - 1023 (1./) 

4) lfe = 0andf*0, then v- (-1) s 2 -1022 (O.r) 
(denormalized numbers) 

5) If e = and f * 0, then v = (-1 ) s (zero) 



121 



IS 10767 (Part 2) : 2001 
IEC 60625-2 (1993) 

9.3.3 Order of transmission 

9.3.3.1 Single precision numbers 

Single precision numbers shall be transmitted in four bytes. The transmission shall be 
structured according to the following relationships between DIO signal lines and the fields. 

DIO 



-876 


5 


4 


3 


2 


1 




SEE 

A 


E 


E 


E 


E 


E 


First byte sent 


MSBE 














E F F 

A A 


F 


F 


F 


F 


F 


Second byte sent 


LSBE MSBF 














F F F 


F 


F 


F 


F 


F 


Third byte sent 


F F F 


F 


F 


F 


F 


F 

A 


Fourth byte sent 










LSBF 





Where 

MSBE is the most significant bit of the exponent. 

LSBE is the least significant bit of the exponent. 

MSBF is the most significant bit of the fraction. 

LSBF is the least significant bit of the fraction. 

S is the sign bit. 

E is an exponent bit. 

F is a fraction bit. 

9.3.3.2 Double precision numbers 

Double precision numbers shall be transmitted in eight bytes. The transmission shall be 
structured according to the following relationships between DIO signal lines and the fields. 

DIO 



-87 


6 


5 


4 3 


2 


1 




S E 

A 


E 


E 


E E 


E 


E 


First byte sent 


MSBE 














E E 


E 


E 

A 


F F 

A 


F 


F 


Second byte sent 




LSBE 


MSBF 








F F 


F 


F 


F F 


F 


F 


Third through seventh byte sent 


F F 


F 


F 


F F 


F 


F 

A 


Last byte sent 



LSBF 
Where 

MSBE is the most significant bit of the exponent. 
LSBE is the least significant bit of the exponent. 
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MSBF is the most significant bit of the fraction. 

LSBF is the least significant bit of the fraction. 

S is the sign bit. 

E is an exponent bit. 

F is a fraction bit. 

9.3.4 Example of single precision number 

An example of a single precision number could be encoded using these four bytes: 



01000010 11100000 


oooooooc 


) 00000000 








« 


Where 








The number then evaluates to: 




binary 


decimal 


v =(-1) s 2 e " 127 (1./) 


s = 





= 


= (-1)°2 6 (1.75) 


e = 


10000101 


«133 


= (64){1.75) 


f = 


110 


= .75 


- 112 
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10 Common commands and queries 

This clause describes common commands and queries. Descriptive information and 
compliance requirements are included for each command. Table 10-1 below lists 
alphabetically all the common command headers defined in this standard. Table 10-2 lists 
the same commands grouped according to function. Syntax of the commands and queries 
follows the conventions of 7.1. 

Table 10-1 - IEC 625-2 common command headers 



Mnemonic 


Name 


Subclause 


*AAD 


Accept Address Command 


10.1 


*CAL? 


Calibration Query 


10.2 


•CLS 


Ciear Status Command 


10.3 


*DDT 


Define Device Trigger Command 


10.4 


*DDT? 


Define Device Trigger Query 


10.5 


•DLF 


Disable Listener Function Command 


10.6 


*DMC 


Define Macro Command 


10.7 


*EMC 


Enable Macro Command 


10.8 


*EMC? 


Enable Macro Query 


10.9 


*ESE 


Standard Event Status Enable Command 


10.10 


•ESE? 


Standard Event Status Enable Query 


10.11 


•ESR? 


Standard Event Status Register Query 


10.12 


•GMC? 


Get Macro Contents Query 


10.13 


MDN? 


Identification Query 


10.14 


•1ST? 


Individual Status Query 


10.15 


•LMC? 


Learn Macro Query 


10.16 


*LRN? 


Learn Device Setup Query 


10.17 


•OPC 


Operation Complete Command 


10.18 


*OPC? 


Operation Complete Query 


10.19 


•OPT? 


Option Identification Query 


10.20 


*PCB 


Pass Control Back Command 


10.21 


•PMC 


Purge Macro Command 


10.22 


•PRE 


Parallel Poll Register Enable Command 


10.23 


•PRE? 


Parallel Poll Register Enable Query 


10.24 


*PSC 


Power On Status Clear Command 


10.25 


•PSC? 


Power On Status Clear Query 


10.26 


•PUD 


Protected User Data Command 


10.27 


•PUD? 


Protected User Data Query 


10.28 


•RCL 


Recall Command 


10.29 


*RDT 


Resource Description Transfer Command 


10.30 


*RDT? 


Resource Description Transfer Query 


10.31 


*RST 


Reset Command 


10.32 


•SAV 


Save Command 


10.33 


•SRE 


Service Request Enable Command 


10.34 


•SRE? 


Service Request Enable Query 


10.35 


•STB? 


Read Status Byte Query 


10.36 


*TRG 


Trigger Command 


10.37 


•TST? 


Self-Test Query 


10.38 


•WAI 


Wait-to-Continue Command 


10.39 
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Table 10-2 - IEC 625-2 common command groups 



Mnemonic 


Group 


Compliance 


Subclause 


*AAD 
•DLF 


Auto Configure 
Auto Configure 


Optional 1 ' 
Optional 1 * 


10.1 
10.6 


•IDN? 

•OPT? 

•PUD 

•PUD? 

•RDT 

'RDT? 


System Data 
System Data 
System Data 
System Data 
System Data 
System Data 


Mandatory 

Optional 

Optional 

Optional 

Optional 

Optional 


10.14 
10.20 
10.27 
10.28 
10.30 
10.31 


•CAL? 
•LRN? 
'RST 
*TST? 


Internal Operations 
Internal Operations 
Internal Operations 
Internal Operations 


Optional 
Optional 
Mandatory 
Mandatory 


10.2 
10.17 
10.32 
10.38 


•OPC 

•OPC? 

•WAI 


Synchronization 
Synchronization 
Synchronization 


Mandatory 
Mandatory 
Mandatory 


10.18 
10.19 
10.39 


*DMC 

•EMC 

•EMC? 

*GMC? 

'LMC? 

•PMC 


Macro 
Macro 
Macro 
Macro 
Macro 
Macro 


Optional 1 ' 
Optional 1 ' 
Optional 11 
Optional 1 ' 
Optional 1 ' 
Optional 1 ' 


10.7 

10.8 

10.9 

10.13 

10.16 

10.22 


'1ST? 
•PRE 
'PRE? 


Parallel Poll 
Parallel Poll 
Parallel Poll 


Mandatory if PP1 
Mandatory if PP1 
Mandatory if PP1 


10.15 
10.23 
10.24 


•CLS 

•ESE 

•ESE? 

*ESR? 

•PSC 

•PSC? 

•SRE 

*SRE? 

•STB? 


Status and Event 
Status and Event 
Status and Event 
Status and Event 
Status and Event 
Status and Event 
Status and Event 
Status and Event 
Status and Event 


Mandatory 

Mandatory 

Mandatory 

Mandatory 

Optional 

Optional 

Mandatory 

Mandatory 

Mandatory 


10.3 

10.10 

10.11 

10.12 

10.25 

10.26 

10.34 

10.35 

10.36 


•DDT 

•DDT? 

*TRG 


Trigger 
Trigger 
Trigger 


Optional if DT1 
Optional if DT1 
Mandatory if DTI 


10.4 
10.5 
10.37 


•PCB 


Controller 


Mandatory if 
other than CO 


10.21 


*RCL 
•SAV 


Stored Settings 
Stored Settings 


Optional '' 
Optional 1 ' 


10.29 
10.33 


1 > If any commands in either the Auto Configure, Macro, or Stored 
Settings groups are implemented then all the commands in that group 
shall be implemented. 



Clause 6.1 .6.1 .1 requires that a device shall generate a Command Error if an unimplemented 
common command is received. 
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10.1 *AAD, Accept Address command 

10.1.1 Function and requirements 

This command, in conjunction with the Address Set protocol, allows the controller to 
detect all address-configurable devices (i.e. devices which implement this command) and 
assign an IEC 625-1 address to each of those devices. An address-configurable device is 
detected when the controller has completed a byte-by-byte search of the device's 
identifier after which time the address is assigned. The Address Set protocol causes this 
identifier search to be executed repeatedly until all address-configurable devices have 
been detected. See 13.4.2, *AAD common command requirements, for detailed 
implementation requirements of this command. 



10.1.2 Syntax 

The syntax for the Assign Address command is defined as a <COMMAND PROGRAM 
HEADER> followed immediately by a <PROGRAM MESSAGE TERMINATOR>. The 
<COMMAND PROGRAM HEADER> is defined as "AAD'. 



10.1.3 Semantics 
See 13.2.2.1. 

10.1.4 Related common commands 

*DLF - Implementation requires this optional command. 

10.1.5 Standard compliance 
Optional 

10.1.6 Error handling 
See 13.2.2.1. 

10.2 *CAL ?, Calibration query 

10.2.1 Function and requirements 

The Calibration query causes a device to perform an internal self-calibration and 
generates a response that indicates whether or not the device completed the self-calibration 
without error. Additional information about any calibration errors may be contained in the 
response, see 10.2.3. 

The Calibration query shall not require any local operator interaction to function. It shall 
not create bus conditions that are violations to the IEC 625-1 or IEC 625-2 standards. 
Otherwise, the scope of the self-calibration is completely at the discretion of the device 

designer. 

Upon completion of *CAL?, the device should be returned to the state just prior to the 
calibration cycle, or other specified operational condition stated in the documentation, 
see 4.9. 
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10.2.2 Query structure 

10.2.2.1 Query syntax 

The syntax for the Calibration query is defined as only a <QUERY PROGRAM HEADER>. 
The <QUERY PROGRAM HEADER> is defined as '*CAL?'. 



10.2.2.2 Response syntax 

The response syntax for the Calibration query is defined as a single <NR1 NUMERIC 
RESPONSE DATA>. The <NR1 NUMERIC RESPONSE DATA> shall be in the 
range -32767 to 32767. 

10.2.3 Response semantics 

A value of zero indicates the calibration completed without any detected errors. 

A value not equal to zero indicates the calibration did not complete or completed with 
errors detected. 

The semantics of the non-zero response shall be completely at the discretion of the device 
designer. 

1 0.2.4 Related common commands 
None. 

10.2.5 Standard compliance 

Optional, requires no other optional commands. 

10.3 *CLS, Clear Status command 

10.3.1 Function and requirements 

The Clear Status command clears status data structures, see 11.1.2, and forces the 
device to the Operation Complete Command Idle State and the Operation Complete Query 
Idle State, see 12.5.2 and 12.5.3. 

If the Clear Status command immediately follows a <PROGRAM MESSAGE 
TERMINATOR>, the Output Queue and the MAV bit will be cleared since any new 
<PROGRAM MESSAGE> after a <PROGRAM MESSAGE TERMINATOR> clears the 
Output Queue, see 6.3. 



10.3.2 Syntax 

The syntax for the Clear Status command is defined as only a <COMMAND PROGRAM 
HEADER>. The <COMMAND PROGRAM HEADER> is defined as '*CLS*. 
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10.3.3 Semantics 
Not applicable. 

10.3.4 Related common commands 
None. 

10.3.5 Standard compliance 
Mandatory. 

10.4 *DDT, Define Device Trigger command 

10.4.1 Function and requirements 

The Define Device Trigger command stores a command sequence which is executed when 
a group execute trigger (GET) IEC 625-1 interface message or a *TRG common command 
is received, see 10.37. The *RST common command shall set the command sequence to a 
device-defined state, see 10.32. 

10.4.2 Syntax 

The syntax for the Define Device Trigger command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by an 
<ARBITRARY BLOCK PROGRAM DATA> element. The <COMMAND PROGRAM 
HEADER> is defined as **DDT\ 

10.4.3 Semantics 

The <ARBITRARY BLOCK PROGRAM DATA> contains either the sequence of 
<PROGRAM MESSAGE UNIT> elements to be executed or a zero-length data field. A 
zero-length field indicates that no action will be taken when a group execute trigger (GET) 
IEC 625-1 interface message or a *TRG common command, see 10.37, Is received. 

1 0.4.4 Related common commands 
*DDT? - This is the companion query. 

10.4.5 Standard compliance 
Optional but requires the DT1 subset. 

10.4.6 Error handling 

10.4.6.1 Oversized block 

An Execution Error, see 6.1.7 and 11.5.1.1.5, shall be reported if the block is too long for 
the device to accept. The maximum length requirement shall be specified in the device's 
documentation. 
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10.4.6.2 Block Data Errors 



Any Command or Execution Errors contained in the block may be either detected 
immediately or deferred until the macro is executed. 

10.4.6.3 Recursion 

If the stored command sequence contains *TRG or the label of an enabled macro whose 
expansion leads to the execution of *TRG then recursion will occur. The application 
program can only stop this recursion by sending OCL or SDC. The device may either 
allow recursion to take place indefinitely or report an Execution Error at a device-defined 
level of recursion. The manner in which recursion is handled shall be stated in the device's 
documentation. See 4.9. 



10.4.7 Example 

•DDT #217TRIG WFM; MEASWFM? 

A GET will immediately trigger a waveform and perform a query which places the acquired 
waveform into the device's Output Queue. 

10.5 *DDT?, Define Device Trigger query 

1 0.5. 1 Function and requirements 

The Define Device Trigger query allows the programmer to examine the command 
sequence which will be executed when a group execute trigger or *TRG command is 
received. 

10.5.2 Query structure 

10.5.2.1 Query syntax 

The syntax for the Define Device Trigger query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as '*DDT?\ 



10.5.2.2 Response syntax 

The response syntax for the Define Device Trigger query is defined as a <DEFINITE 
LENGTH ARBITRARY BLOCK RESPONSE DATA> element. 



10.5.3 Response semantics 

The <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element contains the 
sequence of <PROGRAM MESSAGE UNIT> elements which are executed when a GET or 
*TRG is received. 

The condition of "no command sequence stored" results in a response of a zero-length 
block. 
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1 0.5.4 Related common commands 

*DDT - Implementation requires this optional command. This is the companion command. 

10.5.5 Standard compliance 
Optional but requires the DT1 subset. 

10.6 *DLF, Disable Listener Function command 

10.6.1 Function and requirements 

The Disable Listener Function command causes a device to cease being a listener 
(change to L0 subset). If this command is the first device-specific message received after 
the device leaves DCAS, the device shall cease being a listener within 100 milliseconds 
after the acceptance of the <PROGRAM MESSAGE TERMINATOR*. See 13.4.1, *DLF 
Common Command requirements, for detailed implementation requirements of this 
command. A subsequent DCL message shall restore listener capability. The device shall 
resume listening within 100 milliseconds after entering DCAS. 

10.6.2 Syntax 

The syntax for the Disable Listener Function command is defined as a <COMMAND 
PROGRAM HEADER> followed immediately by a <PROGRAM MESSAGE TERMINATOR>. 
The <COMMAND PROGRAM HEADER> is defined as "*DLF\ 

10.6.3 Semantics 

The *DLF command shall be immediately followed by <PROGRAM MESSAGE TERM IN A- 
TOR> with no parameters. 

10.6.4 Related common commands 

*AAD - Implementation requires this optional command. 

10.6.5 Standard compliance 
Optional. 

10.6.6 Error handling 

See 13.2.1 for further information. 

10.7 *DMC, Define Macro command 

10.7.1 Function and requirements 

The Define Macro command allows the programmer to assign a sequence of zero or more 
<PROGRAM MESSAGE UNIT> elements to a macro label. The sequence is executed 
when the label is received as a <COMMAND PROGRAM HEADER> or <QUERY PROGRAM 
HEADER>. 
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10.7.2 Syntax 



The syntax for the Define Macro command is defined as a <COMMAND PROGRAM 
HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a <STRING 
PROGRAM DATA> followed by a <PROGRAM DATA SEPARATOR> followed by an 
<ARBITRARY BLOCK PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> 
is defined as "DMC. 



10.7.3 Semantics 

The <STRING PROGRAM DATA> contains the macro label. The macro label shall be 
either a <simple command program header>, a <compound command program header>, a 
<simple query program header>, or a <compound query program header>. The macro 
label shall not, however, be either a <common command program header>, see 7.6.1.2, or 
a <common query program header>, see 7.6.2.2. Note that any <white space> before the 
first character of the <STRING PROGRAM DATA> shall not be considered to be a part of 
the macro label. 



The macro label may be the same as a device-specific <COMMAND PROGRAM 
HEADER> or <QUERY PROGRAM HEADER>. In this case, provided macros are enabled, 
see 10.8, the macro label received within a <PROGRAM MESSAGE> shall be executed as 
the macro expansion, not the device-specific command of the same name. That device- 
specific command may still be executed by disabling macros. 



The <ARBITRARY BLOCK PROGRAM DATA> contains the sequence of <PROGRAM 
MESSAGE UNIT> elements being labelled. 

Parameters may be passed to the sequence during execution. Placeholders for 
parameters appear in the sequence as a dollar sign (ISO 7-bit code 24, 36 decimal) 
followed by a single digit in the range 1 to 9 inclusive (ISO 7-bit codes 31-39, 49-57 
decimal). The first <PROGRAM DATA> element following the macro label, when used as a 
header, is substituted for the parameter placeholder labelled $1. The second <PROGRAM 
DATA> element is substituted for $2. This substitution process is continued for up to nine 
parameters. 



The placeholder must appear in the sequence as if it were a complete <PROGRAM 
DATA> element. See 7.3.2 for a description of where <PROGRAM DATA> elements are 
permitted in a <PROGRAM MESSAGE UNIT>. 7.7.7 describes how <PROGRAM DATA> 
elements may appear in an <expression>. 



1 0.7.4 Related common commands 

*PMC - Implementation requires this optional command. 
*GMC? - Implementation requires this optional query. 
*LMC - Implementation requires this optional command. 
*EMC - Implementation requires this optional command. 
*EMC? - Implementation requires this optional query. 
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10.7.5 Standard compliance 
Optional 

10.7.6 Error handling 

10.7.6.1 Oversized block 

An Execution Error, see 6.1.7 and 11.5.1.1.5, shall be reported if the block is too long for 
the device to accept. 

The maximum length requirement is device-specific and shall be specified in the device's 
documentation. 

10.7.6.2 Macro label errors 

A device shall report an Execution Error if the macro label is too long for the device to 

accept. 

The maximum label length is device-specific and shall be specified in the device's 
documentation. 

The device shall report an Execution Error if the macro label does not adhere to the 
<COMMAND PROGRAM HEADER> or <QUERY PROGRAM HEADER> syntax in 7.6. 



10.7.6.3 Block data errors 

Any Command or Execution Errors contained in the block may be either detected 
immediately or deferred until the macro is executed. 

10.7.6.4 Redefining existing macros 

Redefining an existing macro shall cause an Execution Error. 

10.7.6.5 Parameter errors 

If the command sequence requires a different number of parameters than follow the macro 
label, the device shall generate a Command Error. 

The device shall perform normal parameter checking after parameter substitution. 



10.7.6.6 Recursion 

If the sequence of <PROGRAM MESSAGE UNIT> elements contains the label of an 
enabled macro whose expansion leads to execution of the macro being defined then 
recursion will occur. The application program can only stop this recursion by sending DCL 
or SDC. The device may either allow recursion to take place indefinitely or report an 
Execution Error at a device-defined level of recursion. The manner in which recursion is 
handled must be stated in the device documentation. See 4.9. 
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10.7.7 Examples 

1) *DMC "HOME", #18MOVE 0,0 

The macro descriptively labels a command that sends a pen plotter to its home 
position. 

2) *DMC H SLO", #210SPEEDSLOW 

The macro defines an abbreviation of a longer command, thus reducing bus traffic. 

3) *DMC "SETUP1-, #222VOLT 14.5; CURLIM 2E-3 

SETUP1 will be expanded by the device into VOLT 14.5; CURLIM 2E-3 

4) *DMC "TEST.A", #221 BEGFREQ $1 ; ENDFREQ $2 

This example illustrates the use of parameters. This macro expects two parameters. 
The device interprets TEST_A 1000, 2000 the same as BEGFREQ 1000; ENDFREQ 
2000. 

5) *DMC M CLK_EXT H , #219HORIZ: CLOCK: EXT: NEG 

The command which selects an external clock for the horizontal trigger of an 
oscilloscope with negative edge sensitivity is given a shorthand notation. 

6) *DMC "SWEEP_SET", #234START $1 ; MARK1 $1 ; STOP $2; MARK2 $2 

This macro demonstrates the re-use of parameters. The first parameter is used to set 
both the start frequency as well as the position of one of the markers. The second 
parameter sets the stop frequency and another marker. SWEEP_SET 1E6, 5E6 is 
equivalent to START 1 E6; MARK1 1 E6; STOP 5E6; MARK2 5E6. 

10.8 "EMC, Enable Macro command 

10.8.1 Function and requirements 

The Enable Macro command enables and disables expansion of macros. Macro definitions 
are not affected by this command. One use of this command is to turn off macro expansion 
in order to execute a device-specific command with the same name as a macro. 



10.8.2 Syntax 

The syntax for the Enable Macro command is defined as a <COMMAND PROGRAM 
HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a <DECIMAL 
NUMERIC PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> is 
defined as '*EMC\ 



10.8.3 Semantics 

The value of the <DECIMAL NUMERIC PROGRAM DATA> determines whether the 
defined macros are enabled or disabled. 

A <DECIMAL NUMERIC PROGRAM DATA> that rounds to an integer value of zero 
disables any defined macros. 
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A <DECIMAL NUMERIC PROGRAM DATA> that rounds to an integer value not equal to 
zero enables any defined macros. The allowed range shall be -32767 to +32767. 



1 0.8.4 Related common commands 

*PMC - Implementation requires this optional command. 
*GMC? - Implementation requires this optional query. 
*DMC - Implementation requires this optional command. 
*LMC - Implementation requires this optional command. 
*EMC? - Implementation requires this optional query. 

10.8.5 Standard compliance 
Optional 

10.8.6 Error handling 

if the <DECIMAL NUMERIC PROGRAM DATA> element does not round to an integer in 
the range -32767 to +32767 inclusive, an Execution Error shall be reported. 

10.8.7 Example 

Assume an AC power supply has a command of "OUTPUT" which requires two 
parameters: voltage and frequency. The following new definition redefines "OUTPUT" to 
take only one parameter, voltage. The frequency is always 1 kilohertz. 

*DMC "OUTPUT", #228*EMC 0; OUTPUT $1,1000; *EMC 1 

10.9 *EMC ?, Enable Macro query 

10.9.1 Function and requirements 

The Enable Macro query allows the programmer to query whether the macros are enabled. 
A returned value of indicates that macros are disabled. A returned value of 1 indicates 
that macros are enabled. 

10.9.2 Query structure 

10.9.2.1 Query syntax 

The syntax for the Enable Macro query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as , *EMC?'. 

10.9.2.2 Response syntax 

The response syntax for the Enable Macro query is defined as a <NR1 NUMERIC 
RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall be either a 
single ISO 7-bit encoded byte for "0" (30, 48 decimal) or "1" (31, 49 decimal). 
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10.9.3 Response semantics 

A value of indicates that macros are disabled. 

A value of 1 indicates that macros are enabled. 

10.9.4 Related common commands 

*PMC - Implementation requires this optional command. 
*GMC? - Implementation requires this optional query. 
*DMC - Implementation requires this optional command. 
*LMC - Implementation requires this optional command. 
*EMC - Implementation requires this optional command. 

10.9.5 Standard compliance 
Optional 

10.10 *ESE, Standard Event Status Enable command 

10.10.1 Function and requirements 

The Standard Event Status Enable command sets the Standard Event Status Enable 
Register bits as defined in 11.5.1.3. 

10.10.2 Syntax 

The syntax for the Standard Event Status Enable command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a 
<DECIMAL NUMERIC PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> 
is defined as **ESE\ 

10.10.3 Semantics 

The <DECIMAL NUMERIC PROGRAM DATA> when rounded to an integer value and 
expressed in base 2 (binary), represents the bit values of the Standard Event Status 
Enable Register. See 11.4.2.3. 

The value of the integer shall be in the range of through 255. 

1 0.1 0.4 Related common commands 

*ESE? - This is the companion query. 

*PSC - Determines whether the Standard Event Status Enable Register is cleared at 
power-on. 

10.10.5 Standard compliance 
Mandatory 



135 



IS10767(Part2) :2001 
IEC 60625-2 (1993) 

1 0. 1 0.6 Error handling 

An out-of-range integer shall cause an Execution Error, see 11.5.1.1.5. 

10.11 *ESE?, Standard Event Status Enable query 

10.11.1 Function and requirements 

The Standard Event Status Enable query allows the programmer to determine the current 
contents of the Standard Event Status Enable Register. See 11.5.1.3. 

10.11.2 Query structure 

10.11.2.1 Query syntax 

The syntax for the Standard Event Status Enable query is defined as only a <QUERY 
PROGRAM HEADER>. The <QUERY PROGRAM HEADER> is defined as '*ESE?\ 

10.11.2.2 Response syntax 

The response syntax for the Standard Event Status Enable query is defined as a <NR1 
NUMERIC RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall 
be in the range through 255. 

1 0. 1 1 .3 Response semantics 

The <NR1 NUMERIC RESPONSE DATA> integer value expressed in base 2 (binary) 
represents the bit values of the Standard Event Status Enable register. See 1 1 .4.2.3.2. 

1 0. 1 1 .4 Related common commands 
*ESE - This is the companion command. 

10.11.5 Standard compliance 
Mandatory 

10.12 *ESR ?, Standard Event Status Register query 

10.12.1 Function and requirements 

The Standard Event Status Register query allows the programmer to determine the current 
contents of the Standard Event Status Register. Reading the Standard Event Status 
Register clears it. See 11.5.1.2. 

10.12.2 Query structure 

10.12.2.1 Query syntax 

The syntax for the Standard Event Status Register query is defined as only a <QUERY 
PROGRAM HEADER>. The <QUERY PROGRAM HEADER> is defined as '*ESR?\ 
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10.12.2.2 Response syntax 



The response syntax for the Standard Event Status Register query is defined as an <NR1 
NUMERIC RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall 
be in the range through 255. 

10.12.3 Response semantics 

The <NR1 NUMERIC RESPONSE DATA> integer value expressed in base 2 (binary) 
represents the bit values of the Standard Event Status Register. See 1 1 .5.1 . 

10.12.4 Related common commands 
None 

10.12.5 Standard compliance 
Mandatory 

10.13 "GMC7, Get Macro Contents query 

10.13.1 Function and requirements 

The Get Macro Contents query allows the current definition of a macro to be retrieved 
from a device. 

10.13.2 Query structure 

10.13.2.1 Query syntax 

The syntax for the Get Macro Contents query is defined as a <QUERY PROGRAM 
HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a <STRING 
PROGRAM DATA> element. The <QUERY PROGRAM HEADER> is defined as , *GMC?\ 



10.13.2.2 Response syntax 

The response syntax for the Get Macro Contents query is defined as a <DEFINITE 
LENGTH ARBITRARY BLOCK RESPONSE DATA> element. 



10.13.3 Semantics 

10.13.3.1 Parameter semantics 

The data in the <STRING PROGRAM DATA> element must be a currently defined macro 
label. 

10.13.3.2 Response semantics 

The <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element contains the 
<PROGRAM MESSAGE UNIT> sequence which is executed when the macro label is 
received. 
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The condition of "no command sequence stored" results in a response of a zero-length 
block. 

10.13.4 Related common commands 

*PMC - Implementation requires this optional command. 

*EMC - Implementation requires this optional command. 

*EMC? - Implementation requires this optional query. 

*DMC - Implementation requires this optional command. 

*LMC - Implementation requires this optional command. 

10.13.5 Standard compliance 
Optional 

10.13.6 Error handling 

If the programmer attempts to retrieve the contents of an undefined macro, the device 
shall return a zero-length block and report an Execution Error. 

10.14 *IDN ?, Identification query 

10.14.1 Function and requirements 

The intent of the Identification query is for the unique identification of devices over the 
system interface. 

1 0. 1 4.2 Query structure 

10.14.2.1 Query syntax 

The syntax for the Identification query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as "IDN?\ 



10.14.2.2 Response syntax 

The response syntax for the Identification query is defined as an <ARBITRARY ISO 7-bit 
RESPONSE DATA> element. This implies that the *IDN? query should be the last 
<QUERY MESSAGE UNIT> in a TERMINATED PROGRAM MESSAGE> (see 8.7.11 
and 6.4.3). 

10.14.3 Response semantics 

The response is organized into four fields separated by commas. The field definitions are 
as follows: 

Field 1 Manufacturer required 

Field 2 Model required 

Field 3 Serial Number ISO 7-bit character if not available 

Field 4 Firmware Level or equivalent ISO 7-bit character if not available 

NOTE • ISO 7-bit character represents a single ISO 7-bit encoded byte with value 30 (48 decimal). 
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The presence of data in all the fields is mandatory. If either field 3 or 4 is not available, the 
ISO 7-bit character shall be returned for that field. 

A field may contain any ISO 7-bit encoded bytes in the range 20 through 7E (32 through 
126 decimal) except commas {2C, 44 decimal) and semicolons (3B, 59 decimal). 



The overall length of the *IDN? response shall be less than or equal to 72 characters. 

The precise format of fields (except ISO 7-bit character as meaning empty field) is left to 
the device designer. 

If unique serial numbers are used, then ISO 7-bit character shall not be used as a serial 
number. 

10.14.4 Related common commands 
None 

10.14.5 Standard compliance 
Mandatory 

10.14.6 Example 

A hypothetical *IDN? response might appear as follows for a model 246B product from a 
company XYZ Co that has chosen the mnemonic "XYZCO" to represent itself with serial 
number S000- 123-02, and no firmware revision specified. 

XYZCO, 246B, S000-01 23-02,0 

10.15 '1ST?, Individual Status query 

10.15.1 Function and requirements 

The Individual Status query allows the programmer to read the current state of the 
IEC 625-1 defined 'ist' local message in the device, see 11.6.2. 

10.15.2 Query structure 

10.15.2.1 Query syntax 

The syntax for the Individual Status query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as •*IST?\ 



10.15.2.2 Response syntax 

The response syntax for the Individual Status query is defined as an <NR1 NUMERIC 
RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall be a single 
ISO 7-bit encoded byte encoded as a '0' or '1' (30 or 31 , 48 or 49 decimal). 
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10.15.3 Response semantics 

An <NR1 NUMERIC RESPONSE DATA> element with the value (zero) indicates the ist 
local message is FALSE. 

An <NR1 NUMERIC RESPONSE DATA> element with the value 1 (one) indicates the ist 
local message is TRUE. 

The response of this query is dependent upon the current status of the instrument. 

10.15.4 Related common commands 
None 

10.15.5 Standard compliance 

Mandatory for devices implementing the PP1 subset. 

10.16 *LMC? t Learn Macro query 

10.16.1 Function and requirements 

This query returns the currently defined macro labels. 

10.16.2 Query structure 

10.16.2.1 Query syntax 

The syntax for the Learn Macro query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as '*LMC?\ 

10.16.2.2 Response syntax 

The response syntax for the Learn Macro query is defined as a sequence of one or more 
<STRING RESPONSE DATA> elements separated by <RESPONSE DATA SEPARATORS;*. 

10.16.3 Response semantics 

The <STRING RESPONSE DATA> elements contain macro labels currently defined in the 
device, using the *DMC command, see 10.7. 

If no macro labels are defined, then the response shall be a single <STRING RESPONSE 
DATA> with null string data, that is, two consecutive double quote {") marks. 

The response is independent of the macro-enabled or macro-disabled state of the device. 
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1 0. 1 6.4 Related common commands 

See *PMC command, 10.22. 

*PMC - Implementation requires this optional command. 
*DMC - Implementation requires this optional command. 
*EMC - Implementation requires this optional command. 
*EMC? - Implementation requires this optional query. 
*GMC? - Implementation requires this optional query. 

1 0. 1 6.5 Standard compliance 
Optional 

10.17 *LRN?, Learn Device Setup query 

10.17.1 Function and requirements 

The Learn Device Setup query allows the programmer to obtain a sequence of 
<PROGRAM MESSAGE UNIT> elements that may later be used to place the device in the 
state it was in when the *LRN? common query was made. 

1 0.1 7.2 Query structure 

10.17.2.1 Query syntax 

The syntax lor the Learn Device Setup query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as '*LRN?\ 

10.17.2.2 Response syntax 

The response syntax for the Learn Device Setup query is defined as a sequence of one or 
more <RESPONSE MESSAGE UNIT> elements separated by <RESPONSE MESSAGE 
UNIT SEPARATOR> elements. The <RESPONSE MESSAGE UNIT> shall use the path 
shown in 8.3.2 which contains the <RESPONSE HEADER>. 

10.17.3 Response semantics 

The <RESPONSE MESSAGE> is a sequence of one or more <RESPONSE MESSAGE 
UNIT> elements that are directly resendable as <PROGRAM MESSAGE UNIT> elements. 



The device shall be restored to its "learned" state from any other current state upon 
receipt of this <RESPONSE MESSAGE> as a <PROGRAM MESSAGE>. 



The scope of the restored settings is the same as the *RST command, see 10.32. 
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10.17.4 Related common commands 
None 

1 0. 1 7.5 Standard compliance 
Optional 

10.18 *OPC, Operation Complete command 

10.18.1 Function and requirements 

The Operation Complete command causes the device to generate the operation complete 
message in the Standard Event Status Register when alt pending selected device 
operations have been finished. 

See 12.5.2 for details of operation. 

10.18.2 Syntax 

The syntax for the Operation Complete command is defined as only a <COMMAND 
PROGRAM HEADER>. The <COMMAND PROGRAM HEADER> is defined as '*OPC\ 

10.18.3 Semantics 
Not applicable 

10.18.4 Related common commands 
*OPC?, *WAI 

10.18.5 Standard compliance 
Mandatory 

10.19 *OPC7, Operation Complete query 

10.19.1 Function and requirements 

The Operation Complete query places an ISO 7-bit character 1 into the device's Output 
Queue when all pending selected device operations have been finished. 

See 12.5.3 for details of operation. 

10.19.2 Query structure 
10.19.2.1 Query syntax 

The syntax for the Operation Complete query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as '*OPC?\ 
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10.19.2.2 Response syntax 



The response syntax for the Operation Complete query is defined as an <NR1 NUMERIC 
RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall be a single 
ISO 7-bit encoded byte for '1 * (31 , 49 decimal). 

10.19.3 Response semantics 
None 

10.19.4 Related common commands 
*OPC, *WAI 

1 0. 1 9.5 Standard compliance 
Mandatory 

10.20 "OPT?, Option Identification query 

10.20.1 Function and requirements 

The Option Identification query is for identifying reportable device options over the system 
interface. 

1 0.20.2 Query structure 

10.20.2.1 Query syntax 

The syntax for the Option Identification query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as **OPT?\ 

10.20.2.2 Response syntax 

The response syntax for the Option Identification query is defined as an <ARBITRARY ISO 
7-bit RESPONSE DATA> element. This implies that the *OPT? query should be the last 
<QUERY MESSAGE UNIT> in a TERMINATED PROGRAM MESSAGE> (see 8.7.11 and 

6.4.3). 

10.20.3 Response semantics 

The response consists of any number of fields separated by commas. The fields shall 
follow these rules: 

1) Each field must correspond to a reportable option present in the device. The precise 
format of the fields is left to the device designer. 

2) Empty fields are prohibited. Missing reportable options respond with an ISO 7-bit 
character (30, 48 decimal). 

3) Option data may be reported in a position-dependent manner. 

4) A single ISO 7-bit character shall be returned as a response if the device 
contains no reportable options. ISO 7-bit character may not be used as an option 
identification. 
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5) A field may contain any ISO 7-bit-encoded bytes in the range 20 through 7E {32 
through 126 decimal) except commas (2C, 44 decimal) and semicolons (3B, 59 decimal). 

The overall length of the *OPT? response shall be less than or equal to 255 characters. 

1 . 20 .4 Related common commands 
None 

10.20.5 Standard compliance 
Optional 

10.21 "FOB, Pass Control Back 

10.21.1 Function and requirements 

The Pass Control Back command is used to tell a potential controller which address 
should be used when passing control back. 

Any device which implements this command shall have controller capability. Any device 
which has controller capability shall implement this command. 

10.21.2 Syntax 

The syntax for the Pass Control Back command is defined as a <COMMAND PROGRAM 
HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a <DECIMAL 
NUMERIC PROGRAM DATA> element optionally followed by a <PROGRAM DATA 
SEPARATOR> and another <DECIMAL NUMERIC PROGRAM DATA> element. The 
<COMMAND PROGRAM HEADER> is defined as "*PCB\ The first <DECIMAL NUMERIC 
PROGRAM DATA> shall round to an integer value in the range of to 30. The second 
<DECIMAL NUMERIC PROGRAM DATA>, if present, shall round to an integer value in the 
range of to 30. 



10.21.3 Semantics 

The first <DECIMAL NUMERIC PROGRAM DATA> element is rounded to an integer 
whose value is interpreted as the primary address of the controller sending the command. 



The second <DECIMAL NUMERIC PROGRAM DATA> element is rounded to an integer 
whose value is interpreted as the secondary address of the controller sending the 
command. 

A missing second address shall indicate the controller sending this command does not 
have extended addressing. 

1 0.21 .4 Related common commands 
None 
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10.21.5 Standard compliance 

Mandatory for devices that have any controller capability (non-CO devices). See 15.1 .4. 

1 0.21 .6 Error handling 

10.21.6.1 Unable to Pass Control 

A device with no controller capability (CO) shall issue a Command Error if it receives the 
*PCB common command. 

10.21 .6.2 Parameters out of range 

The device receiving the *PCB command shall issue an Execution Error if the value of 
either the first or second parameter is out of its specified range. 

10.22 *PMC, Purge Macros command 

10.22.1 Function and requirements 

The Purge Macros command causes the device to delete all macros that may have been 
previously defined using the *DMC command. All stored macro command sequences and 
labels shall be removed from the device's memory by this command. 

10.22.2 Syntax 

The syntax for the Purge Macros command is defined as only a <COMMAND PROGRAM 
HEADER>. The <COMMAND PROGRAM HEADER> is defined as "PMC. 

10.22.3 Semantics 
Not applicable 

10.22.4 Related common commands 

*EMC - Implementation requires this optional command. 
*EMC? - Implementation requires this optional query. 
*GMC? - Implementation requires this optional query. 
*DMC - Implementation requires this optional command. 
*LMC - Implementation requires this optional command. 

10.22.5 Standard compliance 
Optional 

1 .23 'PRE, Parallel Poll Enable Register Enable command 

10.23.1 Function and requirements 

The Parallel Poll Enable Register Enable command sets the Parallel Poll Register Enable 
bits as defined in 1 1 .6. 
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10.23.2 Syntax 

The syntax for the Parallel Poll Enable Register command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a 
<DECIMAL NUMERIC PROGRAM DATA> element. The <COMMAND PROGRAM 
HEADER> is defined as "PRE'. The <DECIMAL NUMERIC PROGRAM DATA> value shall 
round to an integer in the range to 65535. 



10.23.3 Semantics 

The <DECIMAL NUMERIC PROGRAM DATA> when rounded to an integer value and 
expressed in base 2 (binary) represents the bit values of the Parallel Poll Enable Register. 
See 11.6.1.3. 

10.23.4 Related common commands 
•PRE? - This is the companion query. 

10.23.5 Standard compliance 

Mandatory for devices implementing the PP1 subset. 

10.23.6 Error handling 

If the integer is outside the range to 65535 inclusive, an Execution Error shall be 
reported, see 1 1 .5.1 .1 .5. 

1 0.24 'PRE?, Parallel Poll Enable Register Enable query 

10.24.1 Function and requirements 

The Parallel Poll Enable Register Enable query allows the programmer to determine the 
current contents of the Parallel Poll Enable Register. 



10.24.2 Query structure 

10.24.2.1 Query syntax 

The syntax for the Parallel Poll Enable Register query is defined as only a <QUERY 
PROGRAM HEADER>. The <QUERY PROGRAM HEADER> is defined as "PRE?*. 



10.24.2.2 Response syntax 

The response syntax for the Parallel Poll Enable Register query is defined as an <NR1 
NUMERIC RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> value 
is an integer in the range to 65535. 



10.24.3 Response semantics 

The <NR1 NUMERIC RESPONSE DATA> integer value expressed in base 2 (binary) 
represents the bit values of the Parallel Poll Enable Register. See 11.6.1.2. 
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1 . 24 .4 Related common commands 

'PRE - This is the companion command. 

1 0.24.5 Standard compliance 

Mandatory for devices implementing the PP1 subset. 

10.25 *PSC, Power-on Status Clear command 

10.25.1 Function and requirements 

The Power-on Status Clear command controls the automatic power-on clearing of the 
Service Request Enable Register, the Standard Event Status Enable Register, and the 
Parallel Poll Enable Register, see 11.1.3. No other device functions shall be tied to this 
command. For additional IEC 625-2 power-on requirements, see 5.12. 



10.25.2 Syntax 

The syntax for the Power-on Status Clear command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a 
<DECIMAL NUMERIC PROGRAM DATA> element. The <COMMAND PROGRAM 
HEADER> is defined as "PSC. The <DECIMAL NUMERIC PROGRAM DATA> value shall 
be in the range -32767 to 32767. 



10.25.3 Semantics 

The value of the <DECIMAL NUMERIC PROGRAM DATA> determines whether the 
power-on-clear flag of the device is TRUE or FALSE. 

A <DECIMAL NUMERIC PROGRAM DATA> that rounds to an integer value of zero sets 
the power-on-clear flag FALSE. Sending *PSC 0, therefore, allows instruments to assert 
SRQ after power-on. 



A <DEClMAL NUMERIC PROGRAM DATA> that rounds to an integer value not equal to 
zero sets the power-on-clear flag TRUE. Sending "PSC 1, therefore enables the power-on 
clear and disallows any SRQ assertion after power-on. 



10.25.4 Related common commands 

*PSC? - Implementation requires this optional command. This is the companion query. * 

10.25.5 Standard compliance 
Optional 

10.25.6 Error handling 

If the integer is outside the range -32767 to 32767 inclusive, an Execution Error shall be 
reported, see 11.5.1.1.5. 
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10.25.7 Example 

The command sequence 

*PSC0;*SRE32;*ESE128; 

allows a device to assert SRQ upon completion of power-on. 

10.26 *PSC?, Power-on Status Clear query 

10.26.1 Function and requirements 

The Power-on Status Clear query allows the programmer to query the device's power-on- 
clear flag. A returned value of indicates that the Standard Event Status Enable Register, 
Service Request Enable Register, and the Parallel Poll Enable Register, will retain their 
status when power is restored to the device. A returned value of 1 indicates that the 
registers listed above will be cleared when power is restored to the device, see 11.1.3. 



10.26.2 Query structure 

1 0.26.2. 1 Query syntax 

The syntax for the Power-on Status Clear query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as '*PSC?\ 



10.26.2.2 Response syntax 

The response syntax for the Power-on Status Clear query is defined as only an <NR1 
DECIMAL NUMERIC RESPONSE DATA> element. The <NR1 DECIMAL NUMERIC 
RESPONSE DATA> shall be either a single ISO 7-bit encoded byte for "0" (30, 48 
decimal) or "V (31, 49 decimal). 

10.26.3 Response semantics 

A value of indicates the device's power-on-clear flag is FALSE. 



A value of 1 indicates the device's power-on-clear flag is TRUE. 

1 . 26 .4 Related common commands 

*PSC - Implementation requires this optional command. This is the companion 
command. 

10.26.5 Standard compliance 
Optional 
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1 0.27 *PUD, Protected User Data command 

1 . 27 . 1 Function and requirements 

The Protected User Data command stores data unique to the device such as calibration 
date, usage time, environmental conditions, and inventory control numbers. A minimum 
of 63 bytes shall be provided. The size ot this area shall be specified in the device 
documentation, see 4.9. 

The data shall be protected by some means (such as a password or a recessed switch 
whose access hole can be covered by a protective sticker). The exact protection 
mechanism is a device designer decision. 



Data can be stored only when the protection mechanism is disabled. An enabled 
protection mechanism shall cause an Execution Error to be generated when a *PUD 
command is received. 

The contents ot this memory is for data storage only and shall have no effect on device 
operation except in the response to the *PUD? query, see 10.28. 



10.27.2 Syntax 

The syntax for the Protected User Data command is defined as a <COMMAND PROGRAM 
HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by an 
<ARBITRARY BLOCK PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> 
is defined as **PUD\ 



10.27.3 Semantics 

The semantic meaning of the < ARBITRARY BLOCK PROGRAM DATA> element is beyond 
the scope of this standard. 

10.27.4 Related common commands 

*PUD? - Implementation requires this optional command. This is the companion 
query. 

10.27.5 Standard compliance 
Optional 

1 0.27.6 Error handling 

When the number of <8-bit data bytes> in the <ARBITRARY BLOCK PROGRAM DATA> 
element is more than the size provided, then an Execution Error shall be generated. 



An enabled protection mechanism shall cause an Execution Error to be generated when a 
*PUD command is received. 
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1 0.28 *PUD?, Protected User Data query 

10.28.1 Function and requirements 

The Protected User Data query allows the programmer to retrieve the contents of the 
•PUD storage area. See *PUD command, 10.27. 

10.28.2 Query structure 

10.28.2.1 Query syntax 

The syntax for the Protected User Data query is defined as only a <QUERY PROGRAM 
HEADER>. The <QUERY PROGRAM HEADER> is defined as **PUD?\ 



10.28.2.2 Response syntax 

The response syntax for the Protected User Data query is defined as a <DEFINITE 
LENGTH ARBITRARY BLOCK RESPONSE DATA> element. 



10.28.3 Response semantics 

The data content of the <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> 
shall be -the data last sent to, and accepted by, the device as a parameter to the *PUD 
command. See 10.27. 

1 0. 28.4 Related common commands 

*PUD - Implementation requires this optional command. This is the companion 
command. 

1 . 28 .5 Standard compliance 

Optional 

10.29 *RCl, Recall command 

1 . 29 . 1 Function and requirements 

The Recall command restores the state of the device from a copy stored in local memory. 
The scope of the saved state shall be explicitly stated in the device documentation. The 
scope of the saved state shall be identical with the scope of the state affected by an *RST 
command, see 10.32. 

10.29.2 Syntax 

The syntax for the Recall command is defined as a <COMMAND PROGRAM HEADER> 
followed by a <PftOGRAM HEADER SEPARATOR> followed by <DECIMAL NUMERIC 
PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> is defined as **RCL\ 
The <DECIMAL NUMERIC PROGRAM DATA> value shall be in the range through a 
device specified upper bound. 
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10.29.3 Semantics 



The <DECIMAL NUMERIC PROGRAM DATA> element shall be rounded to an integer 
before interpretation by the device. 

The device shall recall the state of the device from a memory register associated with the 
received integer. The scope of the restored state is the same as the one associated with 
an *RST command. 

The upper bound for the register number shall be the same for both the *SAV and *RCL 
commands, see 10.33. 

The value zero is recommended for any special purpose register, such as a predefined 
power-on setup. 

1 0.29.4 Related common commands 

*RST - The device-defined scope of *RST determines the scope of the *RCL 
command. 

*SAV - Implementation requires this optional command. 
1 . 29 .5 Standard compliance 
Optional 

1 .29 .6 Error handling 

An interpreted value outside of the allowable range shall cause an Execution Error. 

10.30 *RDT, Resource Description Transfer command 

1 . 30 . 1 Function and requirements 

The Resource Description Transfer command allows a Resource Description to be stored 
in a device. 

This command retrieves information describing such characteristics as device 
performance, programming codes, et cetera, in a standard structure. 

The data shall be protected by some means (such as a password or a recessed switch 
whose access hole can be covered by a protective sticker). The exact protection 
mechanism is a device designer decision. 

Data can be stored only when the protection mechanism is disabled. 



This memory is for data storage only and its contents shall have no effect on device 
operation except in the response to the *RDT? query, see 10.31. 



151 



IS10767(Part2):2001 
IEC 60625-2 (1993) 

10.30.2 Syntax 

The syntax for the Resource Description Transfer command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by an 
<ARBITRARY BLOCK PROGRAM DATA> element. The <COMMAND PROGRAM 
HEADER> is defined as , *RDT. 



10.30.3 Semantics 

The data content of the <ARBITRARY BLOCK PROGRAM DATA> is beyond the scope of 
this standard. 

1 0.30.4 Related common commands 

*RDT? - Implementation requires this command. This is the companion query. 

10.30.5 Standard compliance 
Optional 

1 0.30.6 Error handling 

10.30.6.1 Protected data 

An enabled protection mechanism shall cause an Execution Error to be generated when 
an *RDT command is received. 

10.30.6.2 Oversized block 

A block length greater than the device can accept shall generate an Execution Error. The 
device's documentation must specify the maximum block length. 

10.31 *RDT?, Resource Description Transfer query 

10.31.1 Function and requirements 

The Resource Description Transfer query allows a Resource Description to be retrieved 
from a device. The Resource Description may be stored in a read-only memory or in a 
read-write memory settable by the *RDT command. 

10.31 .2 Query structure 

10.31.2.1 Query syntax 

The syntax for the Resource Description Transfer query is defined as only a <QUERY 
PROGRAM HEADER>. The <QUERY PROGRAM HEADER> is defined as "RDT?'. 

10.31.2.2 Response syntax 

The response syntax for the Resource Description Transfer query is defined as a 
<DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA> element. 
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1 0.31 .3 Response semantics 



A non-zero length block shall contain Resource Description data that is either the defined 
built-in Resource Description or exactly what was sent to the device with the last *RDT 
common command. 

A zero-length block indicates the device contains no Resource Description data. 



1 0.31 .4 Related common commands 
*RDT - This is the companion command. 

10.31.5 Standard compliance 
Optional 

10.32 *RST, Reset command 

1 . 32 . 1 Function and requirements 

The Reset command performs a device reset. The Reset command is the third level of 
reset in a three-level reset strategy, see 17.1.2. 

The Reset command shall do the following: 

1) Set the device-specific functions to a known state that is independent of the past-use 
history of the device. Device-specific commands may be provided to program a 
different reset state than the original factory-supplied one. 

2) Set the macro defined by *DDT to a device-defined state, see 10.4. 

3) Disable macros, see 10.8. 

4) Force the device into the OCIS state, see 12.5.2. 

5) Force the device into the OQIS state, see 12.5.3. 

The Reset command explicitly shall NOT affect the following: 

1) The state of the IEC 625-1 interface. 

2) The selected IEC 625-1 address of the device. 

3) The Output Queue. 

4) The Standard Status Register Enable setting. 

5) The Standard Event Status Enable setting. 

6) The power-on-clear flag setting. 

7) Macros defined with the Define Macro Contents command. 

8) Calibration data that affects device specifications. 

9) The Protected User Data query response. 

10) The Resource Description Transfer query response. 
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10.32.2 Syntax 

The syntax for the Reset command is defined as only a <COMMAND PROGRAM 
HEADER>. The <COMMAND PROGRAM HEADER> is defined as '*RST\ 



10.32.3 Semantics 
Not applicable 

10.32.4 Related common commands 
See 10.32.1. 

10.32.5 Standard compliance 
Mandatory 

10.33 *SAV, Save command 

10.33.1 Function and requirements 

The Save command stores the current state of the device in local memory. The scope of 
the saved state shall be explicitly stated in the device documentation. The scope of the 
saved state shall be identical with the scope of the state affected by an *RST command. 

10.33.2 Syntax 

The syntax for the Save command is defined as a <COMMAND PROGRAM HEADER> 
followed by a <PROGRAM HEADER SEPARATOR> followed by a <DECIMAL NUMERIC 
PROGRAM DATA> element. The <COMMAND PROGRAM HEADER> is defined as "SAV. 
The <DECIMAL NUMERIC PROGRAM DATA> value shall be in the range through a 
device specified upper bound. 

10.33.3 Semantics 

The <DECIMAL NUMERIC PROGRAM DATA> element shall be rounded to an integer 
before interpretation by the device. 

The device shall save the current state of the device in a memory register associated with 
the interpreted integer. The scope of the saved state is the same as the one associated 
with an *RST or *LRN? command. 

The upper bound for the register number shall be the same for both the *SAV and *RCL 
commands, see 10.29. 

The value zero is recommended for any special purpose register, such as a predefined 
power-on setup. 

10.33.4 Related common commands 

•RCL - Implementation requires this optional command. 
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10.33.5 Standard compliance 
Optional 

1 0.33.6 Error handling 

A value outside the allowable range shall cause an Execution Error. 

10.34 *SRE, Service Request Enable command 

1 . 34. 1 Function and requirements 

The Service Request Enable command sets the Service Request Enable Register bits as 
defined in 11.3.2. 

10.34.2 Syntax 

The syntax for the Service Request Enable command is defined as a <COMMAND 
PROGRAM HEADER> followed by a <PROGRAM HEADER SEPARATOR> followed by a 
<DECIMAL NUMERIC PROGRAM DATA> element. The <COMMAND PROGRAM 
HEADER> is defined as "SRE\ The <DECIMAL NUMERIC PROGRAM DATA> value is in 
the range of to 255. 

10.34.3 Semantics 

The <DECIMAL NUMERIC PROGRAM DATA> when rounded to an integer value and 
expressed in base 2 (binary) represents the bit values of the Service Request Enable 
Register. See 11.3.2.3. 

For all bits except bit 6, a bit value of one shall indicate an enabled condition. A bit value 
of zero shall indicate a disabled condition. See 11.3.2.3. The bit value of bit 6 shall be 
ignored. 

10.34.4 Related common commands 

*PSC - Determines whether the Service Request Enable Register is cleared at 
power-on. 

*SRE? - This is the companion query. 

10.34.5 Standard compliance 
Mandatory 

10.34.6 Error handling 

The device shall generate an Execution Error if an out-ot- range parameter is received. 

10.35 'SRE?, Service Request Enable query 
1 . 35 . 1 Function and requirements 

The Service Request Enable query allows the programmer to determine the current 
contents of the Service Request Enable Register, see 11.3.2. 

155 



IS 10767 (Part 2): 2001 
IEC 60625-2 (1993) 

1 . 35 .2 Query structure 

10.35.2.1 Query syntax 

The syntax for the Service Request Enable query is defined as only a <QUERY 
PROGRAM HEADER>. The <QUERY PROGRAM HEADER> is defined as ,# SRE?\ 



10.35.2.2 Response syntax 

The response syntax for the Service Request Enable query is defined as an <NR1 
NUMERIC RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> shall 
be in the range to 63 or 128 to 191. 

1 .35 .3 Response semantics 

When converted to binary (base 2), the <NR1 NUMERIC RESPONSE DATA> represents 
the current bit values of the Service Request Enable Register. Bit 6 of the binary 
representation shall always be sent with value zero. 

10.35.4 Related common commands 
*SRE - This is the companion command. 

10.35.5 Standard compliance 
Mandatory 

1 0.36 *S7B ?, Read Status Byte query 

10.36.1 Function and requirements 

The Read Status Byte query allows the programmer to read the status byte and Master 
Summary Status bit. 

10.36.2 Query structure 

10.36.2.1 Query syntax 

The syntax for the Read Status Byte query is defined as only a <QUERY PROGRAM 
HEADER*. The <QUERY PROGRAM HEADER> is defined as "STB?*. 



10.36.2.2 Response syntax 

The response syntax for the Read Status Byte query is defined as an <NR1 NUMERIC 
RESPONSE DATA> element. The <NR1 NUMERIC RESPONSE DATA> value shall be in 
the range of to 255. 

10.36.3 Response semantics 

The <NR1 NUMERIC RESPONSE DATA> integer value expressed in base 2 (binary) 
represents the bit values of the Status Byte Register, see 1 1.2.2.2. 

The MSS (Master Summary Status) bit, not the RQS message, is reported on bit-6, 
see 11.2.2.3. 
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1 0.36.4 Related common commands 
None 

1 0.36.5 Standard compliance 
Mandatory 

10.37 *TRG, Trigger command 

10.37.1 Function and requirements 

The Trigger command is the device-specific analog of the I EC 625-1 defined Group 
Execute Trigger (GET) interface message, and has exactly the same effect as a GET 
when received, parsed, and executed by the device. GET operation is discussed in detail 
in 6.1.4.2.5. 

Note that the *TRG command without *DDT implemented (see 10.4) may generate a 
response. 

10.37.2 Syntax 

The syntax for the Trigger command is defined as only a <COMMAND PROGRAM 
HEADER>. The <COMMAND PROGRAM HEADER> is defined as "*TRG\ 



10.37.3 Semantics 
Not applicable 

1 0.37.4 Related common commands 

*DDT - This optional command may be used to define the action of *TRG. 

1 . 37 . 5 Standard compliance 

Mandatory for devices implementing the DT1 subset. 

10.38 'TST?, Self-Test query 

1 . 38 . 1 Function and requirements 

The Self-Test query causes an internal self-test and places a response into the Output 
Queue indicating whether or not the device completed the self-test without any detected 
errors. Optionally, information on why the self-test was not completed may be contained in 
the response. The scope of the internal self -test shall appear in the device documentation, 
see 4.9. 

The *TST? query shall not require any local operator interaction. It shall not create bus 
conditions that are violations to the IEC 625-1 or IEC 625-2 standards. Otherwise, the 
scope of the self-test is completely at the discretion of the device designer. 
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Upon successful completion of *TST?, the device settings shall be restored to their values 
prior to the *TST?, set to fixed, known values which are stated in the device documentation, 
or set to values defined by the user and stored in local memory. 



10.38.2 Query structure 

10.38.2.1 Query syntax 

The syntax for the Self-Test query is defined as only a <QUERY PROGRAM HEADER>. 
The <QUERY PROGRAM HEADER> is defined as ^TST?'. 



10.38.2.2 Response syntax 

The response syntax for the Self-Test query is defined as an <NR1 NUMERIC 
RESPONSE DATA>. The <NR1 NUMERIC RESPONSE DATA> value shall be in the range 
-32767 to 32767. 

1 0.38 .3 Response semantics 

An <NR1 NUMERIC RESPONSE DATA> with the value of indicates the self-test has 
completed without errors detected. 

An <NR1 NUMERIC RESPONSE DATA> with the value not equal to zero indicates the 
self -test was not completed or was completed with errors detected. 

The semantics of the non-zero response otherwise shall be completely at the discretion of 
the device designer. 

10.38.4 Related common commands 
Not applicable 

1 0.38.5 Standard compliance 
Mandatory 

10.39 *WAI, Wait-to-Continue command 

1 . 39 . 1 Function and requirements 

The Wait-to-Continue command shall prevent the device from executing any further 
commands or queries until the No-Operation- Pending flag is TRUE. See 12.5.1. 



10.39.2 Syntax 

The syntax for the Wait-to-Continue command is defined as only a <COMMAND 
PROGRAM HEADER>. The <COMMAND PROGRAM HEADER> is defined as '*WAI\ 
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10.39.3 Semantics 
Not applicable 

10.39.4 Related common commands 

*OPC, *OPC? in synchronization protocol actions. 

10.39.5 Standard compliance 
Mandatory 

11 Device status reporting 

This clause specifies device requirements involving IEC 625-1 Service Request and 
Parallel Poll functions. These requirements build upon and extend the IEC 625-1 
specifications to provide a detailed status reporting structure. 

A complete model is defined for all status reporting. The IEC 625-1 status byte is part of 
the model. Specific and required status messages are defined. A device-specific status 
reporting model suitable for specific device-specific requirements is presented. 



This section provides a method to transfer the IEC 625-1 status byte to the controller 
using either the IEC 625-1 serial poll or an IEC 625-2-defined common query. Additional 
common commands and queries are provided to obtain more detailed status information. 



11.1 Overview 

11.1.1 Operation 

Figure 11-1 shows the block diagram of the IEC 625-2 Status Reporting Structure. 

IEC 625-2 status reporting utilizes the IEC 625-1 status byte with additional data 
structures and rules. 

The Status Byte Register is composed of seven single-bit "summary-messages" (figure 11-1). 
Each summary-message summarizes an overlaying Status Data Structure. 



Summary-messages always track the current status of the associated Status Data 
Structure. The summary-messages are cleared only by some action of the application 
program which clears the associated Status Data Structure. 

Service Request Enabling and Generation determines if one or more of the seven 
summary-messages will generate the rsv message and thus cause the device to request 
service using its IEC 625-1 Service Request function. 
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The Status Data Structures associated with summary-messages are defined in this clause. 
They follow either: 

- a set of registers to record device events and conditions (register-model); 

- or a Queue to record sequential status or other information (queue model). 

Only two of the seven available Status Data Structures are completely defined by this 
standard: 

- the "Output Queue" is a queue model structure which is summarized by the MAV 
(Message Available) summary-message on bit 4. (DI05 - See figure 11-2); 

- the "Standard Event Status" is a register-model structure which is summarized by 
the ESB (Event Status Bit) summary-message on bit 5. (DI06 - See figure 11-2). 
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Figure 11-1 - I EC 625-2 status^eporting structure overview 

11.1.2 Summary of related common commands 

Table 11-1 lists the IEC 625-2 defined common commands related to this clause. A short 
description and clause references for further information are given for each command. 
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Table 11-1 - Status reporting common commands 



*STB? 
*OPC 

*OPC? 

*CLS 

"ESR? 

*ESE NRf 

*ESE? 

*IST? 

*SRE NRf 
*SRE? 

•PRE NRf 
'PRE? 

•PSC NRf 

*PSC? 



Returns an NR1, which is the value of the IEC 625-1 status byte and the MSS 
(Master Summary Status) summary-message. See 10.36 and 11.2.2.2. 

Sets the "Operation Complete" event bit in the Standard Event Status Register 
when all selected pending device operations have been completed. See 10.18 
and 12.5.2. 

Places a "1" in the Output Queue when all selected pending operations, are 
completed which in turn causes the MAV (Message Available) summary- 
message to be generated. See 10.19 and 12.5.3. 

Clears all Event Registers summarized in the status byte. Alt Queues, except 
the Output Queue, which are summarized in the status byte are emptied. The 
device is forced into the Operation Complete Command Idle State and the Op- 
eration Complete Query Idle State. (See 10.3, 11.2.4, 12.5.2.and 12.5.3). 

Returns an NR1, which is the value of the Standard Event Status Register. 
See 10.12 and 11.5.1. 

Sets the bits of the Standard Event Status Enable Register. See 10.10 and 
11.4.2.3.3. 

Returns an NR1, which is the value of the Standard Event Status Enable Reg- 
ister. See 10.11 and 11.4.2.3.2. 

Returns an NR1, which is the value of the IEC 625-1 ist (individual status) lo- 
cal message. See 10.15 and 11.6.2. 

Sets the bits of the Service Request Enable Register. See 10.34 and 11.3.2.3. 

Returns an NR1, which is the value of the Service Request Enable Register. 
See 10.35 and 11.3.2.2. 

Sets the bits of the Parallel Poll Enable Register. See 10.23 and 11.6.1.3. 

Returns an NR1. which is the value of the Parallel Poll Enable Register. See 
10.24 and 11.6.1.2. 

Sets the power-on-status-dear flag. When set FALSE (value 0), power-on 
service requests are possible. See 10.25, 11.1.3, and 5.12. 

Returns an NR1, which is the value of the state of the power-on-status-clear 
flag. See 10.26, 11.1.3, and 5.12. 



11.1.3 Related IEC 625- 1 defined operations 

Table 11-2 lists the IEC 625-1 defined operations related to this clause. A short 
description and clause references for further information are included with each operation. 
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Table 11-2 - Status reporting IEC 625-1 defined operations 



Power-on 



Serial polf 



Parallel poll 



Clears the Service Request Enable Register, the Standard Event Status Register, 
and the Parallel Poll Enable Register if the power-on-status-clear flag is TRUE or if 
the *PSC command (see 10.25) is not implemented. See 5.12 for additional power- 
on requirements. 

This is the IEC 625-1 serial poll operation. The value of the IEC 625-1 defined STB 
and RQS messages is returned. The value of the status byte is not altered as a 
result of the serial poll, "rsv*, however, is set FALSE by the device causing the 
RQS message to be cleared when the device leaves APRS (Affirmative Poll Re- 
sponse State). 



This is the IEC 625-1 parallel pol 
(see 11.6). 



operation. A one-bit status message is returned 



11.2 Status Byte Register 



Status Summary Messages 
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Figure 11-2 - Status Byte Register 



11.2.1 Definition 



The Status Byte Register contains the device's STB and RQS (or MSS) messages. 
IEC 625-1 defines the method of reporting the STB and RQS message, but leaves the 
setting and clearing protocols and semantics for the STB message undefined. This 
standard further defines specific device STB summary-messages. A MSS (Master 
Summary Status) message is also provided which is output as bit 6 with the STB in 
response to a *STB? common query. See 11.2.2.2. 

1 1 .2.1 .1 IEC 625-2 defined Standard Event Status Bit (ESB) summary-message 

The ESB summary-message is an IEC 625-2 defined message which appears in bit 5 of 
the Status Byte Register. Its state indicates whether or not one or more of the enabled 
IEC 625-2 defined events have occurred since the last reading or clearing of the Standard 
Event Status Register (see 11.5.1). 
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The ESB summary-message is TRUE when an enabled event in the Standard Event 
Status Register is set TRUE. Conversely, the ESB summary-message is FALSE when no 
enabled events are TRUE. See 1 1 .5.1 .2 and 11 .5.1 .3 for detailed operation. 



1 1 .2.1 .2 Standard-defined MAV Queue summary-message 

The MAV (Message Available) summary-message is an IEC 625-2 defined message which 
appears in bit 4 of the Status Byte Register. The state of the message indicates whether 
or not the Output Queue (see 6.1.10) is empty. Whenever the device is ready to accept a 
request by the controller to output data bytes, the MAV summary-message shall be 
TRUE. The MAV summary-message shall be FALSE when the Output Queue is empty. 



This message is used to synchronize information exchange with the controller. The 
controller can, for example, send a query command to the device and then wait for MAV 
to become TRUE. The IEC 625-1 bus is available for other use while an application 
program is waiting for a device to respond. If an application program begins a read 
operation of the Output Queue without first checking for MAV, all system bus activity is 
held up until the device responds. See clause 12 and annex B for device and application 
program synchronization discussion and examples. 



11.2.1.3 Device-defined summary-messages 

Bits through 3 and bit 7 are available for use by the device designer as 
summary-messages. Every device-defined summary-message shall have an associated 
Status Data Structure that follows one of the two models described in 11.4. This structure 
is either a register set for parallel event and condition reporting, or a Queue for sequential 
status and information reporting. The summary-message summarizes the current status of 
the associated Status Data Structure. That is, one or more TRUE and enabled event bits 
in the register- model or a non-empty Queue in the queue model is indicated by a TRUE 
summary-message. See 11.4.2 and 11.4.3. 



1 1 .2.2 Reading the Status Byte Register 

The Status Byte Register can be read with either a serial poll or the *STB? common query. 
Both of these methods read the IEC 625-1 STB message. The value sent for the bit 6 
position is, however, dependent upon the method used. 

1 1 .2.2. 1 Reading with a serial poll 

When serial polled according to IEC 625-1, the device shall return the 7-bit status byte 
plus the single bit IEC 625-1 RQS message. The RQS message is added by the I/O 
Control (see 6.1.4) in accordance with the IEC 625-1 SR state diagram. The status byte 
and RQS message are returned to the controller as a single data byte. Per IEC 625-1 , the 
RQS message indicates if the device was sending SRQ TRUE. Devices shall not send 
the END message during a serial poll. 



For the purpose of this standard, the IEC 625-1 DIO signal lines DI01-6 and 8 correspond 
to bits 0-5 and 7 of the status byte register, respectively. The RQS message is sent on line 
DI07 (bit 6) according to the requirements of IEC 625-1. 
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A TRUE message means that the associated DIO signal line shall be asserted (pulled to a 
low voltage) when the status byte is sent. This convention is standard IEC 625-1 negative 
logic (IEC 625-1, clause 18). 

The STB message portion of the Status Byte Register is read non-destructively. The value 
of the status byte shall not be altered by a serial poll. 

The device shall set the rsv message FALSE when polled (see 11.3.3) so that the RQS 
message will be FALSE if the device is polled again before a new reason for service 
(see 11.3.3) has occurred. 

1 1 .2.2.2 Reading with the *STB? query 

The *STB? common query (see 10.36) shall cause the device to send the contents of the 
Status Byte Register and the MSS (Master Summary Status) summary message 
(see 11.2.2.3) as a single <NR1 NUMERIC RESPONSE DATA> element. 



The response shall represent the sum of the binary-weighted values of the Status Byte 
Register bits 0-5 and 7 (weights 1, 2, 4, 8, 16, 32, and 128 respectively) and the MSS 
summary-message (weight 64). Thus, the response to *STB?, when considered as a 
binary value, is identical to the response to a serial poll except that the MSS summary- 
message appears in bit 6 in place of the RQS message. 



The *STB? common query shall not directly alter the status byte, the MSS summary 
message, the RQS message, or the rsv local message. 

NOTE - The MAV and RQS messages may be indirectly affected, see 11.2.1.2 and 11.3.3 respectively. 



1 1 .2.2.3 Master Summary Status 

The MSS (Master Summary Status) message indicates that the device has at least one 
reason for requesting service. Although the MSS message is sent in bit position 6 of the 
device's response to the *STB? query, it is not sent in response to a serial poll and should 
not be considered part of the IEC 625-1 status byte. 



MSS is the inclusive OR of the bitwise combination (excluding bit 6) of the Status Byte 
(SB) Register and the Service Request Enable (SRE) Register (see 11.3.2); that is: 



MSS is defined as 

(SB Register bit AND SRE Register bit 0) 

OR 
(SB Register bit 1 AND SRE Register bit 1) 

OR 
(SB Register bit 2 AND SRE Register bit 2) 

OR 
(SB Register bit 3 AND SRE Register bit 3) 

OR 
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(SB Register bit 4 AND SRE Register bit 4) 

OR 
(SB Register bit 5 AND SRE Register bit 5) 

OR 
(SB Register bit 7 AND SRE Register bit 7) 

Note that the MSS definition ignores the state of bit 6 in both the Status Byte Register and 
the Service Request Enable Register. For purposes of computing the value of MSS, 
implementors may choose to treat the status byte as an 8-bit value with bit 6 always "0". 



1 1 .2.3 Writing the Status Byte Register 

The Status Byte Register is altered only when the state of the overlaying Status Data 
Structure is altered. This is illustrated in figure 11-1. 

NOTE - Changes in the status byte may affect the state of the rsv local message, MSS summary message, 
and the SRQ interface message as described in 1 1.3.3. 

1 1 .2.4 Clearing the Status Byte Register 

The *CLS common command (see 10.3) shatl cause all Status Data Structures (that is, 
their Event Registers and Queues) to be cleared so that the corresponding summary 
messages are clear. The Output Queue and its MAV summary message are an exception 
and are unaffected by *CLS. 

The entire status byte can be cleared by sending the *CLS command to the device after a 
<PROGRAM MESSAGE TERMINATOR> and before any <QUERY MESSAGE UNIT> 
elements. The Output Queue will be cleared of any unread messages using this method 
(see 6.3.2.3). With the Output Queue empty, the MAV summary message will be FALSE. 
The MSS message in the *STB? response will also go FALSE. The RQS message in the 
Status Byte Register will be FALSE unless the device is in APRS (Affirmative Poll 
Response State). 



11 .3 Service Request enabling 

11.3.1 Operation 

Service Request enabling operation is shown in figure 11-3. 

Service Request enabling allows an application programmer to select which summary 
messages in the Status Byte Register may cause service requests. The Service Request 
Enable Register, illustrated in figure 11-3, is used to select the summary messages. 

11.3.2 Service Request Enable Register 

11.3.21 Function 

The Service Request Enable Register is an 8-bit register that enables corresponding 
summary messages in the Status Byte Register. Thus, the application programmer can 
select reasons for a device to issue a service request by altering the contents of the 
Service Request Enable Register. 
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11.3.2.2 Reading the Service Request Enable Register 



The Service Request Enable Register is read with the *SRE? common query (see 10.35). 
The response message to this query shall be an <NR1 NUMERIC RESPONSE DATA> 
element that represents the sum of the binary-weighted values of the Service Request 
Enable Register (2 raised to the power of the bit number). The value of unused bit 6 shall 
always be zero. 



Status Summary Messages 



Service 

Request 

Generation 




read by Serial Poll 

Status Byte Register 
read by *STB? 



Service Request 
Enable Register 
*SRE <NRf> 
*SRE? 



Figure 11-3- Service Request enabling 

11.3.2.3 Writing the Service Request Enable Register 

The Service Request Enable Register is written with the *SRE common command 
(see 10.34). The *SRE is followed by a <DECIMAL NUMERIC PROGRAM DATA> element. 



The <DECIMAL NUMERIC PROGRAM DATA>, when rounded to an integer value and 
expressed in base 2 (binary), shall represent the bit values of the Service Request Enable 
Register. A bit value of one shall indicate an enabled condition. A bit value of zero shall 
indicate a disabled condition. 

The device shall always ignore the value of bit 6. 

11.3.2.4 Clearing the Service Request Enable Register 

Sending the *SRE common command with a <DECIMAL NUMERIC PROGRAM DATA> 
element value of zero clears the Service Request Enable Register. A cleared register does 
not allow status information to generate an rsv local message and thus, no service 
requests are issued. 
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If the power-on-status-clear flag is TRUE or if *PSC is not implemented (see 11.1.3), the 
Service Request Enable Register shall be cleared upon power-on. The *PSC command is 
used to set the state of the power-on-status-clear flag (see 10.25). 5.12 contains 
additional power-on requirements. 



The Service Request Enable Register shall not be changed by the receipt of the dcas 
message, nor by any device condition other than as stated in this section. 



11.3.3 Service Request generation 

All devices shall implement the Service Request function as described in IEC 625-1. This 
function provides a device with the capabilities of requesting service from the controller 
via the SRQ (Service Request) interface message and reporting that it has requested 
service via the RQS (Request Service) message, which is sent with the status byte in 
response to a serial poll. 

The generation of service requests is controlled by the IEC 625-1 rsv (request service) 
local message which is shown in block diagram form in figure 11-4. This clause describes 
the coupling between the status byte and the IEC 625-1 rsv (request service) message. 
This clause also places additional requirements (beyond those specified in IEC 625-1) on 
the interaction of the IEC 625-1 Acceptor Handshake and the rsv message. These require- 
ments ensure that a device shall: 

1) Assert SRQ when a previously "enabled" condition occurs. 

2) Keep SRQ asserted until the controller has recognized the service request and 
polled the device or has taken specific action to cancel the request (e.g. *CLS 
command). 

3) Release SRQ when polled so that the controller can detect an SRQ from another 

device. 

4) Assert SRQ again if another condition occurs, whether or not the controller has 
cleared the first condition. 



1 1 .3.3.1 New reason for service 

Whenever the contents of the status byte or Service Request Enable Register are 
changed, the device must determine whether the change affects the service request state 
of the device. Device status transitions do not affect the state of the SRQ interface 
message directly. Instead, changes to the status byte and the Service Request Enable 
Register generate the local messages reqt (Request rsv TRUE) and reqf (Request rsv 
FALSE), which are inputs to the Service Request Synchronization block in figure 11-4. The 
output of the Service Request Synchronization block is the local rsv message which 
controls the SRQ interface message as described in IEC 625-1. 



The device shall generate a new service request (set the reqt message TRUE) when: 

1) A bit in the status byte changes from FALSE to TRUE while the corresponding bit in 
the Service Request Enable Register is TRUE. 
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2) A bit in the Service Request Enable Register changes from FALSE to TRUE while 
the corresponding bit in the status byte is TRUE. 

3) A bit in the status byte changes from FALSE to TRUE and the corresponding bit in 
the Service Request Enable Register changes from FALSE to TRUE simultaneously. 

The device shall set the reqt message FALSE when: 

1) The MSS message changes from TRUE to FALSE. 

2) The device enters the SRWS of the Set rsv State Diagram in figure 11-5. 

The device shall stop requesting service (set the reqf message TRUE) when the MSS 
message changes from TRUE to FALSE. 

The device shall set the reqf message FALSE when it enters SRIS (Service Request Idle 
State) of the Set rsv State Diagram in figure 1 1-5 or at power-on. 



The device may also set reqt TRUE whenever the contents of the status byte are 
changed and MSS is TRUE. Because extraneous service requests may be generated, this 
method is not recommended, it is permitted, however, to accommodate certain commercially 
available IEC 625-1 interface circuits. See 11.3.3.4 on implementation techniques. 



In general, the controller application program must never assume that SRQ indicates that 
a new reason for service has occurred, but only that a new reason for service may have 
occurred, and that the application program should check the device status byte to 
determine whether this is indeed the case. 
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Figure 1 1-4 - Service Request generation 
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Figure 11-5 - Set rsv State Diagram 
Table 1 1-3 - Set rsv State Diagram mnemonics 



Messages 


Interface states 


reqt 


Request rsv TRUE 


SRIS 


Service Request Idle State 


reqf 


Request rsv FALSE 


SRWS 


Service Request Wait State 


rsv 


request service 


SRAS 


Service Request Active State 






(APRS) 


Affirmative Poll Response State 



Table 11-4- Set rsv State Diagram message output 



Set rsv state 


rsv message sent 


Device interaction 


SRIS 

SRWS 

SRAS 


F 
F 
T 


not requesting service 
not requesting service 
requesting service 



11.3.3.2 Service Request synchronization 

The Set rsv State Diagram, shown in figure 11-5, synchronizes changes to the device's 
status byte and Service Request Enable Register with the state of the IEC 625-1 SR 
function. It ensures that the device does not change the SRQ or RQS interface messages 
while being polled by the controller, but that the device will 'remember' that the status 
change occurred and will change the state of SRQ and RQS on exit from APRS 
(Affirmative Poll Response State). 

At power-on, or when the reqf local message is TRUE, the device shall enter SRIS 
(Service Request Idle State). While in this state, the device shall send the rsv local 
message FALSE. 
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When the device sets the reqt local message TRUE, the device shall enter SRWS 
(Service Request Wait State). The device shall remain in SRWS and continue to send the 
rsv local message FALSE until the pon or reqf local messages become TRUE or the 
device leaves the IEC 625-1 APRS. Staying in SRWS ensures that the device will not 
change the RQS or SRQ interface messages from FALSE to TRUE while it is being polled 
by the controller. 

If the device is not in APRS, or when it leaves APRS, it shall enter SRAS (Service 
Request Active State). While in this state, the device shall send the rsv local message 
TRUE. The device shall remain in this state until the pon or reqf local messages become 
TRUE or the device enters APRS. 

Upon entry into APRS, the device shall return to SRIS and set rsv FALSE, indicating that 
it has been polled. Note that the device will continue to send the RQS interface message 
TRUE until it has left APRS, according to IEC 625-1. 

11.3.3.3 Status Byte Latch 

If the contents of the Status Byte Register were to be placed directly on to the bus when 
the device was polled, a change in the status byte while the device was in IEC 625-1 
SPAS (Serial Poll Active State) could cause the controller to read the status byte 
incorrectly, due to the changing state of the bus data I/O lines. To prevent this problem, 
devices shall latch the contents of the device status byte and RQS message as 
presented on the DIO lines while the device is in IEC 625-1 SPAS and the IEC 625-1 
source handshake is in SDYS (Source Delay State) or STRS (Source Transfer State). The 
latch guarantees that the status byte will not change on the bus just as the IEC 625-1 SR 
diagram assures that the RQS message will not change. This requirement does not imply 
that the contents of the Status Byte Register may not be changed during this time, only 
that the value presented to the controller on DI01-8 will be stable. In figure 11-4, the 
input from the IEC 625-1 Source Handshake/IEC 625-1 Service Request block determines 
whether or not the Status Byte Latch is transparent. 



1 1 .3.3.4 Implementation techniques 

Many commercially available IEC 625-1 integrated circuits implement the Set rsv State 
Diagram in place of, or in addition to, providing direct control over the rsv local message. 
These circuits also include a status byte buffer which allows the IEC 625-1 control circuit 
to respond to a serial poll without the intervention of device firmware. This section 
describes how the requirements of the IEC 625-2 status reporting model may be met using 
such circuits. It does not sanction the use of specific components or prohibit alternate 
implementations which meet the requirements of this standard, but is meant as a 
discussion of common implementation techniques and pitfalls. 



11.3.3.4.1 Preferred implementation 

The preferred implementation from a device designer's point of view, would be to do the 
following when the contents of the status byte buffer is updated: 

1) set reqt TRUE if "New Reason for Service" is TRUE, or 

2) set reqf TRUE if MSS is FALSE. 
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Here, "New Reason for Service" is an additional argument to the command, generated by 
the device firmware in accordance with 11.3.3.1. This implementation avoids the race 
condition of 11.3.3.4.2 and the spurious service requests of 11.3.3.4.3, but requires that 
nine bits of information be specified with the command (seven bits of status, MSS, and 
New Reason for Service). 

1 1 .3.3.4.2 Allowed Independent Control of STB, reqt, and reqf 

Some integrated circuits allow the contents of the circuit's status byte buffer to be updated 
at any time without changing the state of rsv. Such circuits have three inputs: 

1) A command which updates the contents of the circuit's status byte buffer. 

2) A command which sets reqt TRUE. 

3) A command which sets reqf TRUE. 

TRUE to FALSE transitions of reqt and reqf are generated internally by the circuit 
according to the Set rsv State Diagram. (2) and (3) may be implemented as separate 
commands or as a single command with one argument. 

When the device status byte or Status Enable Register changes, the device firmware 
must: 

1) Update the circuit's status byte buffer. 

2) If there is a New Reason for Service (see 11. 3.3.1), set reqt TRUE. 

3) If there is no reason for service (MSS FALSE), set reqf TRUE. 

Note that there is a race between the device's firmware setting reqt or reqf TRUE and the 
controller's polling the device in response to a previous service request. If the controller 
polls the device after it has updated the status byte buffer but before it has set reqt 
TRUE, the device will generate a service request after the controller has read the new 
status byte. If the controller polls the device after it has updated the status byte buffer 
but before it has set reqf TRUE, the controller will receive the new status byte (which 
shows no reason for service request) with RQS TRUE (indicating a request for service). 
This race does not cause problems in practice, as the controller receives the most recent 
device status in either case. Implementations which set reqt TRUE before updating the 
status byte buffer are not allowed, as they could cause a violation of 1 1 .3.3, rule 2. 



1 1 .3.3.4.3 Allowed Coupled Control of STB, reqt, and reqf 

Some integrated circuits require that one of reqt or reqf be set TRUE each time the status 
byte buffer is updated. Such circuits have one input. 

When the contents of the status byte buffer are updated, the circuit sets: 

1) reqt TRUE if MSS is TRUE, or 

2) reqf TRUE if MSS is FALSE. 

This implementation is allowed by this standard (penultimate paragraph of 11.3.3.1) but 
can generate a service request when a bit in the status byte changes, even if that bit has 
not been enabled to cause a service request. 
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1 1 .3.3.4.4 Other allowed implementations 

Other implementation techniques that satisfy the requirements of this standard may be 
used. 

11.4 Status Data Structures 

11.4.1 Overview 

All device Status Data Structures shall follow either the register model or the queue model 
as defined in 11.4. The Status Data Structures provide a common way for the device 
designer to perform status reporting. Each status data structure has a single "output", a 
summary message which summarizes the structure's state. A FALSE summary-status 
means there is no status to report and TRUE summary status indicates there is status to 
report. 

1 1 .4.2 Status Data Structure - Register model 

The register model Status Data Structure allows the device designer to summarize 
multiple events in a single summary message in the Status Byte Register. Figure 11-6 
illustrates a generalized register model Status Data Structure. 



174 



IS 10767 (Part 2) : 2001 
I EC 60625-2 (1993) 



tr 
O 



Li 



Device Status Continuously 
Monitored 




n-1 



u. 




u 




n n-1 








4 




\AA 



JUL 



&! 



i 



JL-L 



34 



l 



Condition Register 



Transition Filter 
Selects which transitions 
of Condition bits will set 
corresponding event bits 

* = I or I or both 



Event Register 
(latchez Conditions) 



Event Enable Register 

Selects which Events can 
set the Summary Message 



Summary Message 

Figure 11-6 - Status Data Structure - Register model 

11.4.2.1 Condition Registers 
11.4.2.1.1 Function 

A condition is a device state which is either TRUE or FALSE. A Condition Register 
reflects these states in its condition bits. A Condition Register may range in length from 1 
to a maximum of 16 bits and may contain unused bits. Unused bits shall return a zero 
value when read. 

NOTE ■ Some controllers may have difficulty reading a 16-bit unsigned integer into their internal format 
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Typically, the condition bits represent specific device states. Alternately, the condition bits 
may represent summary information from an overlaying secondary Status Data Structure. 
This secondary Status Data Structure shall be one of the Status Data Structures defined in 
11.4, either the register model or the queue model. This overlaying technique may be 
extended to additional layers as required. 



Implementation of Condition Registers is optional, since the sole purpose of a Condition 
Register is to group-related device states or overlaying summary messages so that they 
may be read together. 

This standard does not define any specific Status Data Structure that contains a Condition 
Register. 

1 1 .4.2. 1 .2 Reading Condition Registers 

The device may provide device-specific commands to read any or all of the device's 
Condition Registers. Reading a Condition Register shall not change its contents. 



11.4.2.1.3 Writing Condition Registers 

No device-specific commands shall directly write to a Condition Register. Only changes in 
device state or in an overlaying secondary Status Data Structure may alter the contents of 
a Condition Register. 



1 1 .4.2.1 .4 Clearing Condition Registers 

No device-specific commands shall directly clear a Condition Register. Only changes in 
device state or clearing of an overlaying secondary Status Data Structure may clear a 
condition bit. 

11.4.2.2 Event Registers 

11.4.2.2.1 Function 

Event Registers capture changes in conditions. Each event bit in an event register shall 
correspond to a condition-bit in a Condition Register or (if there is no Condition Register) 
to a specific condition in the device. An event shall become TRUE when the associated 
device condition makes certain device-defined transitions. 



The Event Register definition guarantees that the application cannot miss an event which 
occurs between the reading and clearing of an Event Register. An Event Register bit 
(event bit) shall be set TRUE when an associated event occurs. These bits, once set, are 
"sticky". That is, they cannot be cleared even if they do not reflect the current status of a 
related condition, until they are read by the application. 
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This standard allows the following three transition criteria for setting event bits TRUE (see 
transition filter in figure 1 1 -6): 

1) Positive transition. The event becomes TRUE when its associated condition makes 
a FALSE to TRUE transition only. 

2) Negative transition. The event becomes TRUE when its associated condition makes 
a TRUE to FALSE transition only. 

3) Positive or negative transition. The event becomes TRUE when its associated 
condition makes either a FALSE to TRUE or a TRUE to FALSE transition. 

The device designer shall specify which of the above transition criteria is to be used for 
each event bit. The device may provide device-specific commands to change the 
transition associated with each condition and event bit. 

in all cases, the change of a device condition shall not cause an event bit to go from 
TRUE to FALSE. 

Event Registers may range in length from 1 to a maximum of 16 bits and may contain 
"unused" bits. Unused bits shall be zero when the register is read. 

NOTE - Some controllers may have difficulty reading a 16-bit unsigned integer into their internal format. 



This standard completely specifies only one Event Register, the Standard Event Status 
Register (see 11.5.1). 

11.4.2.2.2 Reading Event Registers 

The device may provide device-specific queries to read any or all of the device's Event 
Registers. The only common query which reads an Event Register is the *ESR? query, 
which reads the Standard Event Status Register (see 10.12 and 11.5.1.2.2). 



11.4.2.2.3 Writing Event Registers 

No device-specific command shall allow the application programmer to directly write bits in 
an Event Register. Commands may, however, clear the entire register. 



1 1 .4.2.2.4 Clearing the Event Registers 

Event Registers shall be cleared when read by a query. Only the Event Register(s) 
queried shall be cleared. 



Additionally, specific commands, in contrast to queries, may be implemented to clear (and 
not read) Event Registers. 

The *CLS common command is a mandatory command (see 10.3) which clears all Event 
Registers. All device-defined Event Registers as well as the Standard Event Status 
Register (see 11.5.1) shall be cleared by *CLS. 
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Event Registers may be cleared at power-on. Event Registers shall not be cleared in any 
way other than as stated above. 

11.4.2.3 Event Enable Registers 

11.4.2.3.1 Function 

Event Enable Registers select which event bits in the corresponding Event Register will 
cause a TRUE summary message when set. Each event bit shall have a corresponding 
enable bit in the Event Enable Register. By use of the enable bits, an application 
programmer can program a device to request service for a single event or an inclusive OR 
of any group of events. 



Each Event Enable Register shall be the same length as the corresponding Event 
Register. Any unused bits in the Event Enable Register shall correspond with unused bits 
in the Event Register. The value of unused bits shall be zero when the Event Enable 
Register is read and shall be ignored when written to by commands. 



This standard completely specifies only one Event Enable Register, the Standard Event 
Status Enable Register (see 11.5.1.3). 

11.4.2.3.2 Reading Event Enable Registers 

The device may provide device-defined queries to read any or all of the device's Event 
Enable Registers. If a device provides a command to write to an Event Enable Register 
and a query to read the same Event Enable Register, the <QUERY HEADER> shall be 
formed by placing a "?" after the <COMMAND HEADER> that sets the register (see 
11.4.2.3.3). 



The query response shall be returned as an <NR1 NUMERIC RESPONSE DATA> 
element. Binary-weighting of the bits shall be used to form the NR1 value. An unused bit 
shall have the value zero. 

The only common query which reads an Event Enable Register is *ESE? which reads the 
Standard Event Status Enable Register (see 10.11 and 11.5.1.3,2). 



1 1 .4.2.3.3 Writing Event Enable Registers 

The device may provide device-specific commands to write to any or all of the device's 
Event Enable Registers. If such a command is implemented, it shall follow the format as 
described in this section. 

The command format shall consist of a device-defined header followed by a <DECIMAL 
NUMERIC PROGRAM DATA> element. The device may also optionally accept an 
EXPRESSION DATA> element that evaluates to a <DECIMAL NUMERIC PROGRAM 
DATA> element. 

The <DECIMAL NUMERIC PROGRAM DATA> when rounded to an integer value and 
expressed in base 2 (binary) shall represent the individual bit values of the Event Enable 
Register. A bit value of one shall indicate an enabled condition. A bit value of zero shall 
indicate a disabled condition. 
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Additional device-specific commands which use other formats are also allowed, if no 
command is provided to write to an Event Enable Register then every used bit in the 
register shall have the value of one and every unused bit shall have a value of zero. 



The only defined common command which writes to an Event Enable Register is the *ESE 
common command, which writes to the Standard Event Status Enable Register 
(see 10.10). 

11.4.2.3.4 Clearing Event Enable Registers 

If the device provides a device-specific command to write to an Event Enable Register 
(see 11.4.2.3.3), the register may be cleared by sending that command with an argument 
of zero (NRf format). 

Event Enable Registers shall be cleared at power-on if the optional *PSC common 
command is not implemented, or if power-on status clear flag is TRUE (see 5.12). 



No other device or interface conditions, including receipt of the dcas message, shall alter 
any Event Enable Register. 

1 1 .4.3 Status Data Structure - Queue model 

The queue model Status Data Structure allows the device designer to report sequential 
status or other information. The presence of such information in a Queue is summarized in 
a summary message. 

One Status Data Structure using the queue model, the Output Queue, with its associated 
MAV summary message (bit 4 of the status byte), is defined by this standard (see 1 1.5.2). 



11.4.3.1 Function 

Figure 11-7 represents the queue model for a Status Data Structure. The Queue is a data 
structure containing a sequential list of information. The Queue is empty when all 
information has been read from the list. 

Items may be placed in the Queue in any order. Items shall be removed from the Queue 
as they are read. The Queue may be cleared under the conditions specified in 11.4.3.4. 
The associated summary message is TRUE if the Queue is not empty and FALSE if it is 

empty. 
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Figure 11-7 - Status Data Structure - Queue model 

All <RESPONSE MESSAGE UNIT> elements in a Queue (other than the Output Queue) 
shall be of the same type (see figure 8-4). The specific content of the data element sent is 
device defined. This rule assures that an application program can know, in advance, the 
format of any data read. 

EXAMPLE: A Queue could contain a list of <CHARACTER RESPONSE DATA> elements. Another Queue 
could contain a list of <NR3 NUMERIC RESPONSE DATA> elements. Yet another could contain a message 
unit with the two elements separated by a comma as: <NR1 NUMERIC RESPONSE DATA>, <STRING 
RESPONSE DATA>. 

The order that the items are read from a Queue (other than the Output Queue) is beyond 
the scope of this standard. A device-defined Queue need not be read in a first-in, first-out 
(FIFO) manner. 



The device designer may impose a maximum length on the Queue structure. Rules 
governing a Queue overflow condition, other than the Output Queue, are beyond the 
scope of this standard. 
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11.4.3.2 Reading a Queue 



A Queue (other than the Output Queue) may be read by optional device-defined queries. 
Such device-defined queries shall cause the item read to be removed from the Queue and 
placed into the Output Queue. 

1 1 .4.3.3 Writing to a Queue 

No Queue shall be written to directly by <PROGRAM MESSAGE> elements. Except for the 
Output Queue, the Queue represents encoded device information, such as a device 
status history or other information as defined by the device designer. 



1 1 .4.3.4 Clearing a Queue 

Queues, except the Output Queue, shall be cleared when any of the following occur: 

1) Receipt of the *CLS command. 

2) Reading all the items in the Queues. Only the Queue that is queried shall have data 
removed. 

3) Other device-specific means. 

NOTE • The Output Queue is a special case and is not cleared by 'CIS but can be cleared under other 
conditions {see 6.3.2.3 and 10.3.1), including method 2. 

1 1 .5 Standard Status Data Structures 

Figure 11-8 represents an overview diagram of the Standard Event Status - Status Data 
Structures. The Standard Event Status Register model is discussed in detail in 11.5.1. 
Output Queue requirements are given in 1 1 .5.2. 

11.5.1 Standard Event Status Register model 

Figure 11-9 represents the operation of the Standard Event Status Register Model. This 
data structure is a specific implementation of the general Status Data Structure register 
model (see 1 1 .4.2) and is required by all devices. 

11.5.1.1 Standard Event Status Register Bit Definitions 

This standard assigns specific IEC 625-2 defined events to specific bits in the Standard 
Event Status Register. 
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Figure 11-8 - Standard Status Data Structures overview 
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Figure 11-9 - Standard Event Status Register model 

11.5.1.1.1 Bits 15 through 8 - Reserved 

Standard Event Status Register bits 15 through 8 are reserved for possible future use by 
IEC. These bit values shall be reported as zero. 

11.5.1.1.2 Bit 7*- Power-on (PON) 

This event bit indicates that an off-to-on transition has occurred in the device's power 

supply. 

11.5.1.1.3 Bit 6 - User Request (URQ) 

This event bit indicates that one of a set of local controls (see 5.6.1.3) defined by the 
device designer as a User Request control has been activated. The setting of this event 
bit shall occur regardless of the IEC 625-1 Remote/Local state of the device. 
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11.5.1.1.4 Bit 5 - Command ERROR (CME) 

Command Errors are detected by the Parser (see 6.1.6). This event bit indicates that one 
of the following events has occurred: 

1) An IEC 625-2 syntax error has been detected by the parser. That is, a controller-to- 
device message was received which is in violation of this standard. Possible violations 
include a data element which violates the device listening formats or whose type is 
unacceptable to the device (see 7.1.2.2). 

2) A semantic error has occurred indicating that an unrecognized header was 
received. Unrecognized headers include incorrect device-specific headers and incorrect 
or unimpiemented IEC 625-2 common commands (clause 10). 

3) A Group Execute Trigger (GET) was entered into the Input Buffer inside a 
<PROGRAM MESSAGE> (see 6.1.4.5 and 6.1.6.1.1). 

When a device detects a Command Error, parser synchronization may be lost. See 6.5.4 
for discussion of parser action after a Command Error. 



The Command Error bit shall not be set to report any other device-specific condition. 
Events that are reported as Command Errors shall not also be reported as Execution 
Errors, Query Errors, or Device-specific Errors. See other bit definitions in this clause. 



11.5.1.1.5 Bit 4 - Execution ERROR (EXE) 

Execution Errors are detected by the Execution Control Block (see 6.1.7). This event bit 
indicates that: 

1) A <PROGRAM DATA> element following a header was evaluated by the device as 
outside of its legal input range or is otherwise inconsistent with the device's 
capabilities. 

2) A valid program message could not be properly executed due to some device 
condition. 

Following an Execution Error, the device shall continue to process the input stream. 



Execution Errors shall be reported by the device after rounding and expression evaluation 
operations have taken place. Rounding a numeric data element, for example, shall not be 
reported as an Execution Error. 

Events that generate Execution Errors shall not also generate Command Errors, Query 
Errors, or Device-specific Errors. See other bit definitions in this clause. 



1 1 .5.1 .1 .6 Bit 3 - Device-specific ERROR (DDE) 

Device-specific Errors are detected by Device Functions (see 6.1.8). This event bit 
indicates that an error has occurred which is neither a Command Error, a Query Error, nor 
an Execution Error. 
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A Device-specific Error is any executed device operation that did not properly complete 
due to some condition, such as overrange. 



Following a Device-specific Error, the device shall continue to process the input stream. 



Device-specific Errors are to be used at the discretion of the device designer. 

Events that generate Device-specific Errors shall not also generate Command Errors, 
Query Errors, or Execution Errors. 

11.5.1.1.7 Bit 2 - Query ERROR (QYE) 

Query Errors are detected by the Output Queue Control (see 6.1.10). This event bit 
indicates that either: 

1) an attempt is being made to read data from the Output Queue when no output is 
either present or pending; 

2) or data in the Output Queue has been lost. 
See 6.5.7 for a complete description. 

The Query Error bit shall not be set to report any other condition. Events that generate 
Query Errors shall not also generate Execution Errors, Command Errors, or Device- 
specific Errors. 



1 1 .5. 1 . 1 .8 Bit 1 - Request Control (RQC) 

This event bit indicates to the controller that the device is requesting permission to 
become the active IEC 625-1 controller-in-charge. 

1 1 .5. 1 . 1 .9 Bit - Operation Complete (OPC) 

This event bit is generated in response to the *OPC command. It, indicates that the device 
has completed all selected pending operations. See 12.5.2 for a discussion of device 
synchronization using this event bit. 

1 1 .5.1 .2 Standard Event Status Register operation 

11.5.1.2.1 Function 

Standard Event Status Register operation follows the rules for event registers in the 
general Status Data Structure register model described in 11.4.2. 



11.5.1.2.2 Reading 

The Standard Event Status Register is destructively read (that is, read and cleared) with 
the *ESR? common query (see 10.12). 
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11.5.1.2.3 Writing 

The Standard Event Status Register cannot be written remotely except to clear it. 

11.5.1.2.4 Clearing 

The Standard Event Status Register shall only be cleared by: 

1) a *CLS command; 

2) a power-on if the power-on-status-clear flag is set TRUE (see note); 

3) a *ESR? query. 

NOTE - A device undergoing a power-on sequence shall initially clear the Standard Event Status Register 
but then record any subsequent events during the device's power-on sequence including setting the PON 
event bit (see 11.5.1.1.2). 

The Standard Event Status Register shall not be cleared by any other device condition. 

1 1 .5.1 .3 Standard Event Status Enable Register operation 

11.5.1.3.1 Function 

The Standard Event Status Enable Register allows one or more events in the Standard 
Event Status Register to be reflected in the ESB summary-message bit. This register 
follows the rules of operation of the Status Data Structure register model for Event Enable 
Registers (11.4.2.3). 

This register is defined for 8 bits, each corresponding to the bits in the Standard Event 
Status Register. Bits 8 through 15 are reserved by the IEC for future use. 

11.5.1.3.2 Reading 

The Standard Event Status Enable Register is read with the common query, *ESE?. Data 
is returned as a binary-weighted <NR1 NUMERIC RESPONSE DATA> (10.11). 

11.5.1.3.3 Writing 

The Standard Event Status Enable Register is written to by the common command, *ESE. 
Data is encoded as <DECIMAL NUMERIC PROGRAM DATA> (see 10.10). 

11.5.1.3.4 Clearing 

The Standard Event Status Enable Register shall be cleared by the following: 

1) Sending *ESE with a data value of zero. 

2) A power-on event if the power-on-status-clear flag is TRUE or the *PSC command 
is not implemented. See *PSC command, 10.25 for further details. 
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No other device or interface conditions, including receipt of the dcas message, shall alter 
this register. 

The Standard Event Status Enable Register shall specifically not be affected by the 
following: 

1) An I EC 625-1 Device Clear function state change. 

2) Sending the *RST common command. 

1 1 .5.2 Standard Queue model 

11.5.2.1 Function 

The Output Queue stores response messages until they are read. The availability of 
output is summarized by the MAV (message available) summary message (bit 4 of the 
status byte). See figure 11-10. 

The MAV summary message is used to synchronize information exchange with the 
controller. See clause 12 for a discussion of device synchronization and clause 6 for 
details on the operation of the Output Queue. 

11.5.2.2 Reading 

The Output Queue shall be a first-in, first-out (FIFO) Queue. The Queue is read by 
handshaking bytes out while the device is in TACS (Talker Active State). 
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and 6.1.10.2.1. 



Figure 11-10 — Standard Queue model 



11.5.2.3 Writing 



The Output Queue interfaces to the system Interface only through the protocols defined 
in clause 6. 

11.5.2.4 Clearing 

The Output Queue shall be cleared in accordance with the protocols of clause 6. 

The *CLS command specifically shall NOT clear the Output Queue except as required in 
6.3.2.3 for any <PROGRAM MESSAGE>. 

11.6 Parallel Poll response handling 

This section describes a method for generating and controlling the IEC 625-1 ist 
(individual status) local message. This message is the status bit sent during a parallel poll 
operation. If a device has PP1 (complete) capability, the device shall implement the data 
structure and associated common commands of this clause (see 1 1.6). 
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11.6.1 Parallel Poll Enable Register 
11.6.1.1 Function 



The Parallel Poll Enable Register shown in figure 11-11 is an 8- to 16-bit wide register. 
Each bit in this register corresponds to a bit in the status byte or a device-defined 
condition. All the bits in the status byte must be used. Up to eight more conditions in the 
device may be associated with the upper eight bits of the Parallel Poll Enable Register. 

NOTE - Some controllers may have difficulty reading a 16-bit unsigned integer into their internal format. 



Each bit in the Parallel Poll Enable Register is ANDed with its corresponding condition or 
summary bit. The resulting bits are ORed together to generate ist. Using the Parallel Poll 
Enable Register allows any single bit or combination of bits to control ist. 



The MSS (Master Summary Status) message is used in place of ROS to report bit 6 of the 
Status Byte Register. MSS is the message returned with the status byte in response to an 
*STB? common query (see 11.2.2.2). 

1 1 .6.1 .2 Reading the Parallel Poll Enable Register 

The contents of the Parallel Poll Enable Register can be queried by sending *PRE?. The 
device responds with an <NR1 NUMERIC RESPONSE DATA> element (see 10.24). 



1 1 .6.1 .3 Writing the Parallel Poll Enable Register 

The Parallel Poll Enable Register is written to by sending the 'PRE command followed by 
a number in <DECIMAL NUMERIC PROGRAM DATA> format to the device. The number is 
converted to binary and placed in the register (see 10.23). 



1 1 .6.1 .4 Clearing the Parallel Poll Enable Register 
The Parallel Poll Enable Register is cleared by: 

1) setting the value of the register to zero; 

2) performing a power-on, if the power-on-status-clear flag is TRUE or if *PSC is not 
implemented. 

1 1 .6.2 Reading ist without a Parallel Poll 

The state of ist can be queried by sending the *IST? common query. The device shall 
return either a "0", if ist is FALSE, or a "1", if ist is TRUE. The number returned shall be an 
<NR1 NUMERIC RESPONSE DATA> element (see 10.15). 
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Figure 11-11 - Parallel Poll response handling data structure 



SECTION 3: SYSTEM RELATED SPECIFICATIONS 
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12 Device/controller synchronization techniques 

12.1 Overview 

This clause describes techniques which may be used to insure synchronization between a 
device and a controller. Three basic techniques are shown: 

• Force sequential execution 

• Wait for response in device's Output Queue 

• Wait for a Service Request 

Detailed examples of these techniques appear in annex B. 

One potential problem with commands that take appreciable time to finish is that the 
application program needs to know when they have finished. Consider the case of a unit 
under test connected to a bus-controllable power supply and a bus-controllable digital 
voltmeter (DVM). The application program needs to know that the power supply output has 
reached the desired voltage setting before it commands the DVM to take a measurement. 
This confirmation that the output is valid is an illustration of what is meant by 
device/controller synchronization. 
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12.2 Sequential and Overlapped Commands 



Device commands fall into two broad classes. The first is the class of "Sequential 
Commands". A Sequential Command is a command that always finishes before the next 
command is executed. 

The other class of commands is "Overlapped Commands". An Overlapped Command is a 
command that allows execution of subsequent commands while the device operations 
initiated by that Overlapped Command are still in progress. 



The device designer chooses whether a device-specific command is Sequential or 
Overlapped. Refer to 12.8.1 for further information. The designer may also choose to 
implement device-specific commands which change a command's type from Sequential to 
Overlapped and vice versa. 

Device documentation shall specify for each command whether it is an Overlapped or 
Sequential Command. 

12.2.1 Illustration of Sequential Commands 

As an illustration, consider the case of a bus-controllable power supply with two outputs. 
The command VOLT1 NRf sets the voltage of one output and VOLT2 NRf sets the voltage 
of the other. If the VOLT commands are Sequential Commands, then the <PROGRAM 
MESSAGE> 

VOLT1 1 .23; VOLT2 1 .00 <PMT> 

(where <PMT> stands for the <PROGRAM MESSAGE TERMINATOR>) would set the first 
output to 1,23 V, and then after that was done, set the second output to 1,00 V. In a 
timeline, the commands appear as 



-3 C- 



VOLT1 VOLT 2 

The symbol T stands for initiation of the associated device operations and "]" stands for 
the completion of those operations. Note that completion of device operations is not the 
same as completion of execution of the command; see 6.1.7 for the distinction. 



12.2.2 Illustration of Overlapped Commands 

If the VOLT commands are Overlapped Commands, the VOLT2 command would begin 
execution before the device operations initiated by the VOLT1 command have completed. 
The timeline is: 
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Some method is needed to show that all commands have finished. Sequential Commands 
are easy because the next command is not executed until the previous Sequential 
Command is finished. Overlapped Commands are more difficult because device 
operations that were initiated several commands ago may still not be finished. 



12.3 Pending-Operation flag 

The purpose of a Pending-Operation flag is to inform the application program that all 
operations started by an Overlapped Command are completed and their result is valid or 
that the operations were aborted. 

Each Overlapped Command shall have a corresponding Pending-Operation flag. A 
Pending-Operation flag is set TRUE when the corresponding command is sent by the 
Execution Control block (6.1.7) to the Device Function block (6.1.8). The flag is set FALSE 
when all the device operations initiated by that command have been completed or aborted 
(e.g., by execution of the *RST command). 



For instance, the operation of changing the output voltage of a power supply is complete 
only when the output is known to have reached the programmed voltage within 
manufacturer specified tolerance. The operation of changing the range on a DVM is 
complete only when the DVM is ready to make a measurement in that range. Figure 12-1 
describes control of these flags. 

12.4 No-Operation-Pending flag 

The No-Operation- Pending flag is used to indicate whether the device has completed 
operations initiated by selected Overlapped Commands. The device designer may choose, 
to' have the No-Operation-Pending flag report the status of ail or a subset of all 
Overlapped Commands. The device designer may provide device-specific commands to 
select which Overlapped Commands shall have their status reported by the No-Operation- 
Pending flag. 

The Pending-Operation flags associated with the selected Overlapped Commands shall be 
OR'd together and the result inverted to generate the No-Operation-Pending flag. The 
No-Operation-Pending flag is TRUE if the device has no selected Overlapped Commands. 
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Figure 12-1 - Pending operation state diagram of selected overlapped commands 



12.5 Controller/device synchronization commands 

The *OPC and *WAI commands and the *OPC? query allow the application programmer to 
maintain controller/device synchronization. 

12.5.1 The *WAI common command 

The *WAI command shall prevent the device from executing any further commands or 
queries until the No-Operation-Pending flag is TRUE. No special provision is made for 
Sequential Commands because any preceding Sequential Command will complete 
execution before the Parser hands the next command (including the *WAI command) to 
the Execution Control block. 



12.5.1 .1 A sample program message without the *WAI command 

An illustration of the use of the *WAI command is the following: Consider a data-logging 
device which is commanded to take a measurement with the device-specific command 
START and to read the present time by TIME?. The START command is an Overlapped 
Command and takes appreciable time to perform. The <TERMINATED PROGRAM 
MESSAGE> 

START; TIME? <PMT> 

causes the device to take a measurement and return the time at which the measurement 
was begun. The timeline and flags are shown in figure 12-3. 
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START 



TIME? 
START Pending-Operation flag 

' ___/ V 



f 



No-Operation-Pending flag 

; \ ^ 



Figure 12-2 - Timing diagram - Sample program message not using *WAI command 

12.5.1 .2 A sample program message with the *WAI command 

The TERMINATED PROGRAM MESSAGE> 

START; *WAI; TIME? <PMT> 

forces the TIME? query response to be the time at which the measurement was finished. 
Thus the *WAl command allows the application programmer to force sequential execution 
of Overlapped Commands. The timeline and flags are shown in figure 12-3. 



START 



■DC- 



'WAI TIME? 



START Pending-Operation Nag 
t 
f 






No-Operation-Pending flag 



; \ / 

Figure 12-3 - Timing diagram - Sample program message using *WAI command 



Detailed illustrations of the use of the *WAI command appear in annex B. 

The *WAI command's holdoff action shall be cancelled by power-on and by the dcas 
message. Since the *WAI command holds off the device execution control until the 
No-Operation-Pending flag is TRUE, the commands *RST and *CLS can have no effect on 
the operation of *WAI. 
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12.5.2 The *OPC common command 



The *OPC command allows synchronization between a controller and several devices. 
The OPC event-bit in the ESR (Standard Event Status Register) is used to effect the 
synchronization. Detailed illustrations of the use of the *OPC command appear in annex B. 



12.5.2.1 The Operation Complete command state diagram 

The *OPC command shall perform as described in figure 12-4 and the descriptions given 
throughout clause 12.5.2. 



pon 

or 

dcas 

or 

•CLS 

or 

*RST 

flag - TRUE 



Operation Complete 
Command Idle State 

OCIS 




*OPC executed 


Operation Complete 
Command Active State 

OCAS 






No-Operation -Pending 



OPC event-bit set in ESR 



Figure 12-4 - Operation Complete command state diagram 

1 2.5.2.1 .1 OCIS (Operation Complete Command Idle State) 
The following conditions place the device into OCIS: 

• Power-on (see 5.12) 

• Receipt of the dcas message (see 5.8) 

• *CLS is executed (see 1 0.3) 

• *RST is executed (see 10.32) 

The device shall exit OCIS and enter OCAS (Operation Complete Command Active State) 
when the *OPC command is executed. 

12.5.2.1.2 OCAS (Operation Complete Command Active State) 

In OCAS the device continuously senses the No-Operation-Pending flag. When the 
No-Operation-Pending flag is sensed TRUE the device shall set the OPC event-bit in the 
ESR (Standard Event Status Register), exit OCAS, and enter OCIS (Operation Complete 
Command Idle State). 

1 2.5.2.2 Sample use of the *OPC command 

The previous example in 12.1 of the power supply, DVM, and device under test illustrates 
the effect of *OPC. The problem is to program the DVM to take a measurement only after 
the power supply has finished changing its output voltage. 
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The application programmer may enable bit (corresponding to the OPC event-bit) in the 
Standard Event Status Enable Register and also bit 5 (corresponding to the ESB summary 
message) in the Service Request Enable Register so that the device will request service 
whenever the OPC event-bit becomes TRUE. A TERMINATED PROGRAM MESSAGE> of 



*CLS; VOLT 5.20; *OPC <PMT> 

then commands the power supply to clear its Standard Event Status Register and Status 
Byte, set its output voltage to 5.20 V, and then request service once the output voltage is 
valid. After the service request is detected the application program can then command the 
OVM to take a measurement. The timeline and flags are shown in figure 12-5. 



c — nc- 



*CLS VOLT 



•OPC 
VOLT Pending -Operation flag 

' _^ V 



f 



No-Operation-Pending flag 
t 



OCAS 



\ f 






OPC Event bit 



;e^ /■ ' 

Figure 12-5 - Timing diagram - Sample program message using the *OPC command 



12.5.3 The 'OPC? common query 

The *OPC? query allows synchronization between a controller and a device using the 
MAV bit in the Status Byte or a read of the Output Queue. Detailed illustrations of the use 
of this function appear in annex B. Note that unlike the *OPC command described in 
12.5.2, the *OPC? query does not in any way affect the OPC Event bit in the ESR 
(Standard Event Status Register). 



12.5.3.1 The *OPC? query diagram 

The *OPC? query shall perform as described in figure 12-6 and the descriptions given 
throughout 12.5.3. 
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12.5.3.1 .1 OQIS (Operation Complete Query Idle State) 
The following conditions place the device in OQIS: 

• Power-on (see 5.12) 

• receipt of the dcas message (see 5.8) 

• *CLS is executed (see 10.3) 

• *RST is executed (see 10.32) 

The device shall exit OQIS and enter OQAS (Operation Complete Query Active State) 
when the *OPC? query is executed. 



pon 

or 

dcas 

or 

•CIS 

or 

•RST 



Operation Complete 
Query Idle State 

OQIS 


*OPC? executed 


Operation Complete 
Query Active State 

OQAS 




No-Operation-Pending 



" 1 * Placed In Output 
Queue 



Figure 12-6 - Operation Complete query state diagram 

12.5.3.1 .2 OQAS (Operation Complete Query Active State) 

In OQAS the device continuously senses the No-Operation-Pending flag. When the No- 
Operation-Pending flag is sensed TRUE the device shall place an ISO 7-bit character 1 in 
the Output Queue. A consequence of this action is that the MAV bit in the Status Byte will 
become TRUE. The device shall also exit OQAS and enter OQIS. 

12.5.3.2 Sample use of the *OPC? query - No Service Request 

The following technique of using the *OPC? query avoids the use of service requests and 
serial polls. Bit 4 (corresponding to the MAV summary-message) in the Service Request 
Enable Register is set to a value of zero (disabled). The TERMINATED PROGRAM 
MESSAQE> 

VOLT 5.20; *OPC? <PMT> 

is then sent to the power supply. The application program then attempts to read the 
*OPC? query response from the power supply. The device will not put a response to the 
*OPC? into the Output Queue until the voltage is valid. After the response is received the 
controller commands the DVM to take a measurement. 
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12.5.3.3 Sample use of the *OPC? query - Service Request method 

The following technique makes use of service request and serial poll. Bit 4 (corresponding 
to the MAV summary-message) in the Service Request Enable register is set to a value of 
one (enabled) and the TERMINATED PROGRAM MESSAGE> 

VOLT 5.20; *OPC? <PMT> 

is sent to the power supply. The power supply requests service when the output voltage is 
valid. Then the DVM is commanded to take a measurement. 

While reading the response to the *OPC? query removes the complication of dealing with 
service requests and the attendant serial poll, it has the penalty that both the system bus 
and the controller handshake are in a temporary holdoff state while the controller is 
waiting to read the *OPC? query response. The method using the *OPC command and the 
OPC event-bit in the Standard Event Status Register or the method using the *OPC? 
query and the MAV summary-message in the Status Byte Register both require the use of 
a serial poll. However, they allow both the system bus and the controller to perform 
other operations while waiting for the service request. 



12.6 Synchronization with External-Control-Signals 

The techniques described in this section may be used to provide synchronization between 
External Control signals as defined in 5.6.1.4 and the application program. The device 
designer may provide device-specific Overlapped Commands that depend upon receipt of 
external-control-signals. A device operation may be initiated by the command and 
completed as a consequence of receipt of an external-control-signal. 



For example, consider a DVM that has the command TRG:EXT" to select external trigger, 
and the Overlapped Command (and query) "MEAS?" to take a measurement when 
triggered. The DVM will make the Pending-Operation flag TRUE upon receipt of the 
following TERMINATED PROGRAM MESSAGE> 

*CLS; TRG:EXT; MEAS? <PMT> 

After the external trigger signal is applied the measurement is taken, and then the 
Pending-Operation flag is made FALSE. 

All the synchronization methods using the *WAI, *OPC commands and the *OPC? query 
may be used with Overlapped Commands that use external-control-signals. 



12.7 Improper usage of *OPC and *OPC? 

The *OPC command and *OPC? query are intended to appear as the last <PROGRAM 
MESSAGE UNIT> in a <PROGRAM MESSAGE>. The result of the TERMINATED 
PROGRAM MESSAGE> 

*CLS; OL1; OL2; *OPC; OL3 <PMT> 
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will depend upon the relative timing of the completion of the device operations started by 
the "OL1" and "OL2" Overlapped Commands and the execution of the "OL3" Overlapped 
Command. 

The No-Operation-Pending flag may still be FALSE when the Overlapped Command "OL3" 
is executed. In this case the OPC event-bit becomes TRUE when the Overlapped 
Command "OL3" is finished, since the No-Operation- Pending flag does not go TRUE 
before the Pending Operation flag corresponding to the "OL3" command goes TRUE. The 
timeline and flags for this case are as shown in figure 12-7. 
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*OPC OL3 
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OL3 Pending-Operation flag 
t 
f 



/ V 



No-Operation-Pending flag 

; \ s 



OCAS 



y v 



OPC Event Bit 



lEEE^ /" 



Figure 12-7 - Timing diagram - Improper operation, example 1 

However, if the No-Operation-Pending flag becomes TRUE before the Overlapped 
Command "OL3" is executed then the OPC event-bit will already be TRUE. The timeline 
and flags for this case are as shown in figure 12-8. 
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12.8 Design considerations 

This clause is intended to guide the device designer in choosing which commands should 
be Overlapped Commands and which should be Sequential. It also provides guidance to 
the device designer about how the No-Operation-Pending flag shall be generated. 



12.8.1 Overlapped commands 

In general, a device designer will want to make commands sequential if they complete in a 
short time and overlapped if they take a long time to complete. "Short time" and "long 
time" must be considered in the context of other device commands. 



For example, consider a data logger that can back up its data to tape without interrupting 
the logging of new data. This back-up takes one hour to complete, so the back-up 
operation should be overlapped. Assume that logging new data takes one minute. This is a 
long time compared to many of the device operations (e.g. responding to *STB? query) but 
a short time compared to the back-up operation. 



Consider the case where the device designer chooses to make the data-logging operation 
overlapped. When the application program commands the data logger to take a 
measurement, the No-Operation-Pending flag will go FALSE for one minute and then 
TRUE. If the application program commands the data logger to take a measurement while 
a back-up operation is in progress, the No-Operation-Pending flag will remain FALSE until 
the back-up completes, possibly as long as one hour. During this time, the application 
program has no way of knowing whether the measurement is complete. 



Now consider the case where the device designer chooses to make the data logging 
operation sequential. This may be an acceptable solution since the "MEASURE" command 
by itself will not cause a delay. If the controller attempts to send additional commands 
before the data-logging operation is complete, then the controller and bus will be "stalled" 
until the data logger is ready to execute the new commands. Note that this method is very 
sensitive to device implementation. If the device has no Input Buffer, sending the 
TERMINATED PROGRAM MESSAGE> 



MEASURE;<space><PMT> 
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could cause the device to wait after the semicolon until the measurement completes and it 
is ready to accept the rest of the <TERMINATED PROGRAM MESSAGE>. 
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Figure 12-8 - Timing diagram - Improper operation, example 2 

NOTE - If OL1 or OL2 operation is extended beyond *OPC, then OL3 will decide the time at which the 
OPC event occurs. 

A "reasonable length" Input Buffer (see 6.1.5) would be large enough to hold the 
command, extra white space, and <PROGRAM MESSAGE TERMINATOR> so that the bus 
handshake would not be stalled during the measurement. 



If the hypothetical data logger had to return some data to the controller at the end of each 
measurement, sequential operation would not be acceptable since the controller and bus 
would be stalled for the duration of each measurement. In this case, the device designer 
might choose to ignore the "BACKUP" Pending-Operation flag when determining the state 
of the No-Operation-Pending flag. (The "device-defined subset" in 12.4 would not include 
the "BACKUP" Pending-Operation flag.) This would allow the application programmer to 
use the standard *WAI, *OPC, and *OPC? commands to synchronize measurements. The 
device designer would have to provide some other device-specific means of determining 
when the bac-kup operation had completed. 
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The device designer could also create a device-specific command to select which 
pending-operation flags would affect the No-Operation-Pending flag. This would allow the 
application programmer to use the *WAI, *OPC, and *OPC? commands to wait for the 
measurement to complete, for the back-up to complete, or both. 



12.8.2 Execution Error handling 

If a <PROGRAM MESSAGE> causes an Execution Error, the associated operation is 
aborted, the Pending-Operation flag is made FALSE, and the device reports an Execution 
Error. 

12.8.3 Operation complete 

The device designer shall determine the point in time when Overlapped Commands 
complete their associated device operations. The following principles shall be followed in 
determining when to set the Pending-Operation flag FALSE for each associated 
device-defined Overlapped Command. 

The device designer must realize the importance of the requirements of this clause. These 
requirements allow application software to determine when external components of a 
system may utilize the results of a device operation. Thus the device shall not 
prematurely report that an operation is complete. The device may indicate that the 
operation is complete anytime after the operation really is complete. 



The device designer may include special hardware, such as sensors, for the device to 
determine when an operation is complete. Alternatively, the device designer may design 
the device to wait for an appropriate amount of time to elapse. Any method is acceptable 
as long as the results of an operation are valid whenever the device reports that operation 
to be complete. A device that reports an operation to be complete when, in fact, it is not, 
is either misapplied, out of calibration, or defective. A signal generator connected to a 
short circuit is an example of a misapplication. For each command the device 
documentation shall specify the functional criteria that are met when an operation 
complete message is generated in response to that command. 



The criteria that shall be satisfied before an operation is reported complete are shown 
separately for two classes of devices: stimulus-devices (see 12.8.3.1) and response- 
devices (see 12.8.3.2). A device may contain functions of both types. 



12.8.3.1 Stimulus-devices 

A stimulus-device generates a signal which is used to stimulate an external piece of 
equipment in a system. An example of a stimulus-device is a power supply. 

When a device-specific Overlapped Command causes the device to generate a signal the 
device shall not indicate that the associated pending operation is complete until one of the 
following has occurred: 

1) the signal on its output port is in a valid state, 

2) or the operation has been aborted. 



202 



IS 10767 (Part 2): 2001 
I EC 60625-2 (1993) 

The device may provide device-specific commands which allow the application 
programmer to select which characteristics of the signal applied at the device's output 
port will set the Pending-Operation flag FALSE. For example, these commands might 
select the accuracy to which an output signal must settle before the device indicates that 
an operation is complete. 

12.8.3.2 Response-devices 

A response-device is a device which responds to an externally provided signal. An 
example of a response-device is a DVM which measures an external signal. 

When a device-specific Overlapped Command causes the device to respond to an 
external signal the device shall not indicate that the associated pending operation is 
complete until one of the following has occurred: 

1) the response is complete, 

2) or the operation has been aborted, 

3) or the device is ready for the controlter to begin a read operation in response to a 
query Overlapped Command. 

The device may provide device-specific commands which allow the application 
programmer to select which characteristic(s) of the response sets the Pending-Operation 
flag FALSE. For example, these commands might select the degree of accuracy to which 
the signal is measured. 

13 Automatic system configuration 

13.1 Introduction 

When a test system is configured or reconfigured, addresses must be assigned to the 
devices so that the controller application program can send messages to and receive 
messages from the desired devices. This clause provides tools in the form of protocols, 
commands, and guidelines to automate this task for devices regardless of compliance 
with EEC 625-2. It also discusses how the information generated by the tools can be used 
by an application program to automatically adjust to test system hardware changes. 



13.2 Overview 

The following protocol and common command combinations support automatic 
configuration: 

Controller protocol Common command Purpose of combination 

Find Listeners Disable Listener (*DLF) To find non-address-configurable IEC 625-1 

(see 17.6) (see 10.6 and 13.4.1) and IEC 625-2 devices (°AAD/°DLF not 

implemented) 

Set Address Accept Address (*AAD) To find address-configurable IEC 625-2 

(see 17.7) (see 10.1 and 13.4.2) devices (*AADrDLF implemented) 

An overview of the use of these combinations is given below and does not represent an 
actual implementation. Figure 13-1 illustrates a comprehensive search of devices on an 
IEC 625-1 bus. 
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START 



Search for non-address-configurable devices 
(Find Listeners/Disable Listener combination) 



Search for address-configurable devices 
(Set Address/Accept Address combination) 



END 



Figure 13-1 - Comprehensive Device Search 

The Non-Address-Configurable Device Search in turn is comprised of the elements shown 
in figure 13-2 followed by the Address-Configurable Device Search elements in figure 
13-3. 



START 



Disable Listener function of address-configurable 
devices using Disable Listener 



Search for non -address-configurable devices 
using Find Listeners 



END 



Figure 13-2 - Non-Address-Configurable Device Search 
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START 



Return address-configurable devices to 
the listening state using DCL 



Search for address-configurable devices 
using Set Address 



END 



Figure 13-3 - Address-Configurable Device Search 

The Find Listeners controller protocol mentioned in figure 13-2 and Set Address in figure 
13-3 are further described in figures 13-4 and 13-5 respectively. Set Address protocol 
interacts with the Accept Address common command of figure 13-6 to implement the ad- 
dress configurable Device Search. 
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mary addresses in the input list found to be 
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Figure 13-4 - Find Listeners protocol 
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Procedure 



Procedure purpose 



Calling routine 



Set- Address procedure (17.7.5.1) 



Configure-Device procedure (17.7.5.5) 



Acquire-Field procedure (17.7.5.3) 



Acquire-Byte procedure (17.7.5.4) 



Invokes the Set Address protocol and may be contained in the application 
program, or a utility, etc. 

Searches for address-configurable devices in the input address space, 
manages the acquisition of device identifier fields (see 13.4.2.2) and 
configures the device. 

Updates configuration table to include the device detected and assigns 
an address to that device. 

Manages the acquisition of bytes within a device identifier field 
(see 13.4.2.2.). 

Performs a binary search to identify the lowest active device identifier 
data byte being presented by a device(s) and instruct only that device to 
continue participating. 



Figure 13-5 - Set Address protocol 
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Present-Identifier- Byte 
Procedure (13.4.2.4.4) 



Procedure Purpose 

Invokes the common command upon receiving 
*AAD and resides in the device's firmware. 



Causes identifier to be repeatedly presented to 
the controller until the entire identifier is acquired 
by the controller. 



Ensures fields are presented to the controller in 
the correct order (via Present-Identifier Field) and 
accepts an address if successfully detected by the 
controller. If the device is not successfully detected 
the Accept-Address procedure is informed. 



Ensures bytes within a field are presented in order 
to the controller and informs the Present-Device- 
Identifier procedure if the device is not 
successfully detected. 



Guides controller to the current byte of the 
device's identifier and, if unable, informs 
Present-Identifier-Field procedure that the device 
was not successfully detected. 



Figure 13-6 - Accept Address common command 

The Set Address controller protocol and Accept Address common command Interact as 
follows. 

The Present-ldentifier-Byte procedure in each device endeavours to guide the controller 
to its current byte which is detected by the Acquire-Byte procedure in the controller. The 
Acquire-Byte procedure acquires each byte via a binary search until one entire identifier is 
acquired (see annex C). At this point, only one device is left participating, and the 
controller's Configure-Device procedure assigns the device an address which is 
accepted by the device's Present-Device-Identifier procedure. This scenario repeats until 
all devices have been detected and have been assigned addresses. 
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13.3 Generic approach to automatic system configuration 

13.3.1 Address assignment 

The method of address assignment described below is a generic approach and may be 
tailored to specific requirements. The non-address-configurable devices are detected first, 
followed by address-configurable devices. The application program is responsible for 
supplying a list of addresses to be searched for the presence of devices and a table 
describing the desired final configuration. 

13.3.1.1 Types of devices 

Three types of devices may reside on an I EC 625-1 bus: 

• non-lEC 625-2 devices 

• non-address-configurable devices (no *AAD) 

• address-configurable devices (implement *AAD). 

The first two types are defined as non-address-configurable. The third type is defined as 
address-configurable. 

13.3.1.2 Non-address-configurable device detection 

Non-address-configurable devices are detected by an address probing routine (controller 
Find Listeners protocol, see 17.6) which searches each address specified in the input 
address list for a listener device or devices. During the poll, the listener capabilities of the 
address-configurable devices are disabled by the *DLF common command (Disable 
Listener Function, see 10.6) to prevent them from responding to the poll. The protocol 
performs the search by noting if the NDAC line is TRUE after the address is sent. If so, a 
device(s) exist(s). Otherwise, the address location is empty. If the address location is 
occupied, the address is stored in a non-address-configurable address table. 



13.3.1 .3 Address-configurable device detection 

Address-configurable devices are detected via a binary searching routine (controller Set 
Address protocol, see 17.7, and the *AAD Common Command). Each device seeks 
detection by guiding the controller to its identifier with its Listener and Service Request 
functions. The identifier is made up of the first three fields of the *IDN? query response 
(manufacturer, model number and serial number) and the device's current listen address. 
Once an identifier is detected, the controller assigns an address to the associated device 
according to a user supplied configuration table. The table will normally exclude 
addresses occupied by the non-address-configurable devices to prevent communication 
conflicts. 
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13.3.1.4 System configuration table 



After all devices have been detected, the application program may create a system 
configuration table that lists each of the devices detected by these protocols. This 
application program may also place other data into the table, such as that returned by the 
*RDT?" or *PUD? common queries. A number of the controller protocols described in 
clause 17 requires an input list of addresses. The application program may use the system 
configuration table to provide these addresses to the protocols. Thus, the application 
software can automatically adjust itself in response to any configuration or reconfiguration 
of the test system which it controls. 



13.3.1.5 Limitations 

The Find Listeners protocol cannot detect multiple devices at the same address. Thus, the 
user is responsible for ensuring that each non-address-configurable device resides at a 
unique address. The protocol also will not work if there are devices in the system which 
take more than 1 ms to cease listening after the controller sends ATN FALSE when they 
are not addressed. 



The Set Address protocol will unambiguously detect every address-configurable device 
regardless of its address except when an identifier is not unique. Such a situation can 
occur if two like devices have "0" for a serial number and their addresses are the same at 
the start of the search. If the user changes one of these addresses, then the searching 
method will operate correctly. 



The Set Address protocol will not work if any non-address-configurabie device in the 
system asserts SRQ TRUE during the Set Address protocol. In some cases, serial polling 
all devices found by the Find Listener protocol before starting the Set Address Protocol 
may be sufficient to clear the SRQ line. In other cases, some other means must be used to 
make these devices set SRQ FALSE for the duration of the protocol. 



13.3.1.6 Procedure 

1) Send alt primary and extended listen addresses which cause all devices in the 
system to listen. 

2) Send dcas message *DLF <NL A END> and wait 100 ms which disables all 
address-configurable devices from listening. 

3) Send *CLS <NL A END>. This command clears the Query Error in all non-address- 
configurable devices caused by receiving the unrecognized command, *DLF, and 
causes them to release SRQ. 

4) Perform Find Listeners protocol at all addresses. Each address is tested for the 
presence of non-address-configurable devices. Afterwards, all of those devices are 
unlistened. 

5) Place the non-address-configurable devices (found in the previous step) into the 
system configuration table. 

6) Send DCL and wait 100 ms which restores address-configurable devices to normal 
listening operation (LACS or LADS). 
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7) Perform the Set Address protocol on all currently listen-addressed devices. This 
protocol identifies all address-configurable devices, but does not change their current 
addresses. 

8) Place address-configurable devices into the system configuration table. 

9) Perform the Set Address protocol again to assign new addresses to address- 
configurable devices. The application program should include only devices which need 
to be assigned new addresses in this step. (If the application program does not need to 
assign specific addresses to specific devices, this step may be omitted.) 

At the conclusion of this procedure, the system configuration table contains a list of 

• address-configurabie devices, including their manufacturer, model number, serial 
number, and address 

• non-address-configurabie device addresses. 



13.3.2 Device identification 

The manufacturer and model number of a device may be used by an application to assign 
a type of device (e.g. DVM, power supply) to a particular bus address. In some 
applications, keeping a record of which specific pieces of test equipment that were used 
for a given test is important. For example, this information can be used to maintain a 
calibration history of a device. 

13.3.2.1 Addition of non-lEC 625-2 devices 

At the conclusion of the previous procedure, the system configuration table includes the 
manufacturer, model number, serial number, and address for each address-configurable 
device. The table contains only the address for each non-address-configurable device. 
The application must obtain the remaining three pieces of information for non-lEC 625-2 
devices from the keyboard, a disk file, or other source. Non-lEC 625-2 devices must be 
identified in the system configuration table so that they can be excluded from IEC 625-2 
specific procedures. 



13.3.2.2 Addition of IEC 625-2 non-address-configurable devices 

After the non-lEC 625-2 devices are identified, the application may use the *IDN?" query 
to fill in the rest of the table entries for non-address-configurable devices. 



13.3.2.3 Additional configuration commands 

A number of common commands and queries are available to provide information useful 
within an automatic test system. These commands include *PUD and *PUD? (Protected 
User Data), *RDT and *RDT? (Resource Description Transfer), *CAL? (Calibration), and 
*OPT? (Option Identification Query). 
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Because these and other related common commands are optional, the application program 
must be able to determine if a particular device has implemented a given command or 
query. The application may derive this information from its own knowledge of a device's 
capabilities from a Resource Description. Another way is to send the command or query, 
and use the device's required status reporting facilities to determine if the device does 
not implement the command. For example, the application program could determine if the 
device implements the *RDT? common query with the following procedure: 

NOTE - Quotes around data strings are not part of the data sent. 

1) Send "*ESE 1;*SRE 32;*CLS<NL A END>". This TERMINATED PROGRAM MES- 
SAGE> enables reporting of the OPC event (only) and clears the status registers. 

2) Send "*RDT?;*OPC<NL A END>". The device may or may not implement the *RDT? 
query, but is required to implement the *OPC (operation complete) command. The 
device will set the OPC event bit in the Standard Event Status Register when it 
executes the *OPC command. (An assumption is made that the device has no pending 
operations, which is a reasonable assumption during system initialization.) The device 
will eventually set the Event Status Bit (ESB, bit 5) in the device's Status Byte 
Register, and cause a service request. 

3) The application may wait for the service request signal or may repeatedly poll the 
device until the device's status byte indicates a service request (RQS TRUE). (The 
application should not assume that a service request is caused by this device, but 
should always check the device status byte before continuing.) 

4) Send "*ESR?<NL A END>" without attempting to read the *RDT? query response. 
Note that this sequence is a violation of the normal device message exchange protocol 
(see clause 6). and may cause the device to indicate a Query Error, which the 
application program is choosing to ignore. 

5) Read the *ESR? response. The Operation Complete (OPC, bit 0) event bit should 
be TRUE (value of 1). The Command Error (CME, bit 5) event bit will be FALSE (value 
of 0) if the device does implement the *RDT? common query and TRUE (value of 1) if 
the device does not. The application program should ignore the Query Error (QYE, bit 2) 
event bit, which may or may not be set. 

13.4 Detailed requirements of the auto configure commands 

1 3.4. 1 *DLF common command requirements 

The *DLF common command shall disable the device's normal Listener function until a 
DCL (Device Clear) interface message, an IFC (interface clear) interface message, or pon 
(power-on) is received. The device shall enter LIDS (Listener Idle State) within 100 ms 
after the device's acceptor handshake enters AWNS (Acceptor Wait for New Cycle State) 
on the last byte of the following TERMINATED PROGRAM MESSAGE>: 



*DLF<NL A END> 

Where 'DLF' may be in any mixture of upper-case or lower-case. This timing requirement 
does not apply if: 
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1) this is not the first <PROGRAM MESSAGE UNIT> received after the dcas message, 

2) if any other syntactic elements are sent with the *DLF command before the 
<PROGRAM MESSAGE TERMINATOR>, 

3) or if any <PROGRAM MESSAGE TERMINATOR> other than <NL A END> is used. 

If the device receives a *DLF command which is not the first <PROGRAM MESSAGE 
UNIT> received after the dcas message, or is not the only <PROGRAM MESSAGE UNIT> 
in a <PROGRAM MESSAGE>, it shall indicate an Execution Error and shall not execute 
the *DLF command. 

The device shall not indicate an error solely because the *DLF is preceded or followed by 
white space or because a <PROGRAM MESSAGE TERMINATOR> other than <NL A END> 
is used, but it may not meet the timing requirement. 



After receiving *DLF, the Listener function shall remain disabled until the device receives 
a dcas message. During this time, the Talker function, status reporting mechanism, and 
Controller function (if present) may continue normal operation or may be disabled. The 
device shall return to normal operation with the Listener function in LADS (Listener 
Addressed State) or LACS (Listener Active State) within 100 ms after receiving the dcas 
message. The device shall also return to normal operation in LIDS (Listener Idle State) 
following power-on or the IFC (Interface Clear) interface message, but shall not return to 
normal operation because of any other IEC 625-1 bus condition. 



13.4.2 'AAD common command requirements 

The *AAD common command prepares the device to participate in the controller's Set 
Address protocol. The device's normal input buffering, command processing, and 
status-reporting mechanisms are disabled during the protocol. 

13.4.2.1 Device protocol initiation 

The device shall be ready to participate in the Set Address protocol within 100 ms after 
the device's Acceptor Handshake function enters AWNS on the last byte of the following 
TERMINATED PROGRAM MESSAGE>: 

*AAD<NL A END> 

where 'AAD' may be in any mixture of upper-case or lower-case. This timing requirement 
does not apply if: 

1) this is not the first <PROGRAM MESSAGE UNIT> received after the dcas message. 

2) any other syntactic elements are sent with the *AAD command before the 
<PROGRAM MESSAGE TERMINATOR>, 

3) or if any <PROGRAM MESSAGE TERMINATOR> other than <NL A END> is used. 
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If the device receives a *AAD command which is not the first <PROGRAM MESSAGE 
UNIT> received after the dcas message, or is not the only <PROGRAM MESSAGE UNIT> 
in a <PROGRAM MESSAGE>, it shall indicate an Execution Error and shall not execute 
the *AAD command. 

The device shall not Indicate an error solely because the *AAD is preceded or followed by 
white space or a <PROGRAM MESSAGE TERMINATOR> other than <NL A END> is used, 
but it may not meet the timing requirement. 



The device shall return to normal operation at the end of the Set Address protocol or 
following pon (power-on), the IFC (Interface Clear) interface message, or the dcas 
message, but shall not return to normal operation because of any other I EC 625-1 bus 
condition. If a device receives a pon, IFC, or dcas prior to being assigned an address, it 
shall retain the address it possessed prior to the execution of this command. 



13.4.2.2 Device identifier 

Each device which implements this command shall have an identifier made up of four 
fields: 

- manufacturer 

- model number 

- serial number 

- current address 

For proper operation of this command, each byte of the identifier must have a decimal 
value greater than 31 and less than 127, and the identifier must be unique among all 
devices in the system. The first three fields of this identifier shall be identical to the first 
three fields of the *IDN? (Identification Query) query response. The fourth field shall 
consist of a single data byte (decimal value 32 through 62) which is identical to the 
device's current listen address and, if the device implements extended addressing, 
another data byte (decimal 96 through 126) that is identical to the device's current 
secondary address. 

13.4.2.3 Protocol operation 
13.4.2.3.1 Overview 

During the Set Address protocol, the controller attempts to identify each address- 
configurable device within the system by searching for a unique identifier. The controller 
identifies one device in each pass through the protocol. The search ordering is 
lexicographic by fields, with characters ordered according to their ISO 7-bit codes. If a 
field in one device's identifier is an initial substring of the same field in another device's 
identifier, the device with the longer field will be found first. During the pass, devices drop 
out of the search until only the first device (in the above ordering) is left. At the end of the 
pass, the controller assigns an address to that device. Once assigned an address, a 
device ignores subsequent bus traffic until all devices have been identified. The 
controller then restarts the search with the remaining devices. This process continues 
until all address-configurable devices have been identified and assigned new addresses. 
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13.4.2.3.2 SR interface function 

The controller uses a binary search technique to find each byte in the identifier. The 
device uses its SR interface function to guide the controller through the search. The 
device shall send the rsv message FALSE if the value of the data byte presented by the 
controller is less than or equal to the value of the byte in the device's identifier. The 
device shall send the rsv message TRUE if the value of the data byte presented by the 
controller is greater than the value of the byte in the device's identifier. The device shall 
send the rsv message FALSE when the search has reached the end of an identifier field, 
or when the search has reached the end of the identifier. 



13.4.2.3.3 Timing requirements 

The device shall send the correct value of the rsv message within 1 ms of the device's 
acceptor handshake entering AWNS. The device shall not make a transition from ANRS to 
ACRS (in preparation for the next byte) until the rsv message is stable. 



13.4.2.3.4 Address assignment 

When the device has been identified, it shall accept one data byte from the controller. 
The value of this byte is the device's new listen address. The device shall set its primary 
address to the value of the lower five bits of this byte, and shall set its primary talk 
address so that the lower five bits of MLA and MTA are identical. 



A device utilizing extended addressing shall accept an additional data byte from the 
controller. The device shall set its secondary address to the value of the lower five bits of 
this byte. 

The device's Listener function shall not enter LIDS (Listener Idle State) when the new 
addresses are assigned, but shall remain in LACS (Listener Active State). 



13.4.2.4 Algorithms 

The following algorithms define a correct implementation of the *AAD command. The 
device shall implement these algorithms or a functionally equivalent procedure. 



13.4.2.4.1 Accept-Address procedure 

Accept-Address watches for the STX character, ISO 7-bit character with the value 02 (2 
decimal), which marks the start of a search pass. Present-Device-Identifier is called to 
present the device's identifier. If the device is not first in the search order, Present-Device- 
Identifier returns with the device-detected flag set FALSE. If the device-detected flag is 
FALSE, Accept-Address continues reading and discarding bytes until another STX 
character is received, indicating the start of a new search pass. If the device-detected flag 
is TRUE, this device has been identified. Accept-Address reads and discards all data until 
a dcas message restores normal operation. 
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BEGIN Accept-Address 

Disable input buffer 
Disable normal command processing 
Disable device status reporting 
Set rsv message FALSE 

Set device-detected to FALSE 
WHILE device-detected is FALSE 
BEGIN 
REPEAT 
Read data-byte 
UNTIL data-byte is ISO 7-bit STX ('decimal value of 2*) 
Perform Present-Device-Identifier 

(* Present-Device-Identifier will set device-detected TRUE if 
the controller has successfully identified this device*) 
END 

WHILE NOT in DCAS 
Read and discard data bytes 

Enable input buffer 

Enable normal command processing 

Enable device status reporting 

END Accept-Address 

13.4.2.4.2 Present-Device-Identifier procedure 

Present-Device-Identifier presents the four fields of the device's identifier to the 
controller. If all four fields match, Present-Device-Identifier accepts the device's new 
address from the controller. If any field does not match, Present-Device-Identifier returns 
immediately. 

BEGIN Present-Device-Identifier 
Set current-field to manufacturer 
Set participating TRUE 
WHILE participating is TRUE 
BEGIN 
Perform Present-ldentifier-Field 

(*Present-ldentifier-Field will set participating FALSE if there is 
another device on the bus whose identifier comes prior 
to this device's identifier in the search order.*) 
IF participating is TRUE 
THEN 
BEGIN 
IF current-field is address 
THEN 
BEGIN 
Set device-detected to TRUE 
Set participating to FALSE 
END 
ELSE 
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CASE current-field OF 
BEGIN 
manufacturer: Set current-field to model number 
model number: Set current-field to serial number 
serial number: Set current-field to address 
END 
END 
END 
IF device detected is TRUE 
THEN 
BEGIN 

Read data-byte ('Signals end of identifier through SRQ being FALSE*) 
IF data-byte is 127 
THEN 
BEGIN 
Read data-byte 

Assume primary address indicated by data-byte 
IF device implements extended addressing 
THEN 
BEGIN 
Read data-byte 

Assume secondary address indicated by data-byte 
END 
END 
ELSE 
Set device-detected to FALSE 

(* Another device has an address field which is a superset 
of this device's address field*) 
END 
END Present-Device-Identifier 

13.4.2.4.3 Present-ldentifier-Field procedure 

Present-ldentifier-Field presents successive bytes of the current search field to the 
controller. 

BEGIN Present-Identifier-Field 

Set identifier-byte-pointer to beginning of current-field 

Set end-of-field to FALSE 
WHILE participating is TRUE AND end-of-field is FALSE 

BEGIN 
Perform Present-Identifier-Byte 

(* Present-Identifier-Byte will set participating FALSE if 

there is another device on the bus whose identifier 

comes prior to this device's identifier in the search order/) 
IF identifier-byte-pointer is at end of current-field 

THEN 

Set end-of-field to TRUE 
ELSE 

Increment identHier-byte-pointer 
END 
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IF participating is TRUE 
THEN 
BEGIN 
('Signals end of this field by returning SRQ FALSE for the 

search of the next character.*) 
Read data-byte 
Set rsv message FALSE 
END 
END Present-ldentifier-Field 

13.4.2.4.4 Present-Identifier-Byte procedure 

Present-Identifier-Byte presents one byte of the device's identifier to the controller. It 
uses the SR interface function to guide the controller through a binary search for the 
lowest-value identifier byte in the system. The controller signals the end of the search by 
presenting the identifier byte with the most significant bit set. Present-Identifier-Byte 
checks that this byte matches the device's identifier byte. The participating flag is set 
FALSE if the byte does not match. This mismatch will cause a return to Accept- Address, 
which will discard data bytes until the next pass. 



BEGIN Present-Identifier-Byte 
Read data-byte 
IF data-byte is 127 
THEN 
BEGIN 
Set rsv message TRUE 
Set DI08-detect FALSE 
WHILE DI08-detect is FALSE 
BEGIN 

Read data-byte 

IF data-byte is between and 127 
THEN 
BEGIN 
(*The controller is guided through the binary search 
by the device with the lowest-value byte at 
the current position within the identifier.*) 
IF data-byte is GREATER THAN current identifier byte 
THEN 

Set rsv message TRUE 
ELSE 

Set rsv message FALSE 
END 
ELSE 
BEGIN 
(*The controller has set the most significant bit of the byte 
to indicate that it is done searching and this is the value 
of the lowest valued byte in this position. 
It is placing that byte on the bus so that the device can 
determine if it should continue participating in the search.*) 
Set rsv message FALSE 
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Set DI08-detect TRUE 
IF data-byte is NOT EQUAL to 
(current identifier byte + 128) 
THEN 
Set participating FALSE 
END 
END 
END 

ELSE (*A superset field, excluding address, of another device is 
detected*) 
BEGIN 
Set rsv message FALSE 
Set participating FALSE 
END 

END PresenHdentifier-Byte 

13.5 Additional automatic configuration techniques 

Addresses and identifications of test system devices represent only a portion of the 
information the controller needs in order to perform tasks requested by the user. That is, 
calibration dates, programming codes, etc., are required by the controller to ensure that 
the test requirements of the user are transformed into valid actions by the test system. 



The basic techniques provided in this section may be utilized by the application 
programmer to ease the task of configuring and reconfiguring automatic test systems. This 
section describes only a few of the configuration techniques that are possible. For 
example, the system configuration table can be expanded to include service request 
masks that are automatically sent to the devices when the table is created or updated. 



13.6 Examples 

See annex C, Automatic system configuration, for application examples. 

SECTION 4: CONTROLLER RELATED SPECIFICATIONS 

14 Controller compliance criteria 

A device must have certain capabilities as described in previous clauses. This clause lists 
the capabilities which this standard requires in a system controller. A controller may 
optionally contain additional capabilities. Any optional controller capabilities which are 
described by this standard are also listed. 



Compliance for a controller is divided into several areas which are considered separately. 
A controller must satisfy all the required functionality in each of the areas in order to 
comply with this standard. 
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14.1 IEC 625- 1 requirements 

A controller shall contain these IEC 625-1 subsets listed in table 14-1 and no others: 



Table 14-1 - IEC 625-1 requirements 



IEC 625-1 
Interface function 


IEC 625-1 
Subsets 


IEC 625-2 
Subclause 


Source Handshake 


SH1 


15.1.2 


Acceptor Handshake 


AH1 


15.1.3 


Talker 


if C5. C7, C9, C11.C17, C19, C21,orC23 
then T5, T6. TE5. or TE6 
else T7. T8, TE7. or TE8 


15.1.2 


Listener 


L3, L4, LE3, or LE4 


15.1.3 


Service Request 


if C5, C7, C9, C11. C17, C19. C21, or C23 
then SR1 
else SRO 




Remote Local 


RLO or RL1 




Parallel Poll 


PPO or PP1 




Device Clear 


DCO or DC1 




Device Trigger 


DTO or DT1 




Controller 




15.1.1 


System Controller 


CI 




Send IPC and Take Charge 


C2 




Send REN 


C3 




Respond to SRQ 


C4 




Send Interface Messages and 
Take Control Synchronously 


one of C5, C7, C9, C11, C13. C15, 
C17, C19, C21. C23, C25, or C27 





A controller shall meet the requirements of IEC 625-1. It shall also meet all requirements 
stated in clause 15 of this standard. 

14.2 Message Exchange requirements 

14.2.1 Required control sequences 

Each of the control sequences listed in table 14-2 and described in clause 16, shall be 
implemented individually in a controller. 
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Table 14-2 - Required control sequences 



Control sequence 


Subclause 


Requires IEC 625-1 
Subset 


SEND COMMAND 


16.2.1 


one of C5-C28 


SEND SETUP 


16.2.2 


one of C5-C28 


SEND DATA BYTES 


16.2.3 


one of C5-C28 


SEND 


16.2.4 


one of C5-C28 


RECEIVE SETUP 


16.2.5 


one of C5-C28 


RECEIVE RESPONSE MESSAGE 


16.2.6 


one of C5-C28 


RECEIVE 


16.2.7 


one of C5-C28 


SEND IFC 


16.2.8 


C2 


DEVICE CLEAR 


16.2.9 


one of C5-C28 


ENABLE LOCAL CONTROLS 


16.2.10 


C3 


ENABLE REMOTE 


16.2.11 


C3 


SET RWLS 


16.2.12 


C3 and one of C5-C28 


SEND LLO 


16.2.13 


C3 and one of C5-C28 


READ STATUS BYTE 


16.2.18 


one of C5-C28 


TRIGGER 


16.2.19 


one of C5-C28 



1 4.2.2 Optional control sequences 

Each of the control sequences listed in table 14-3 and described in clause 16, may be 
implemented individually in a controller. 

Table 14-3 - Optional control sequences 



Control sequence 


Subclause 


Requires IEC 625-1 
Subset 


PASS CONTROL 
PERFORM PARALLEL POLL 
PARALLEL POLL CONFIGURE 
PARALLEL POLL UNCONFIGURE 


16.2.4 
16.2.5 
16.2.6 
16.2.7 


C5.C7.C9, or C1 1 
C5. C9. C13. C17. C21. or C25 
C5, C9, C13. C17. C21. or C25 
C5. C9. C13. CI 7. C21. or C2S 



14.3 Protocols 

14.3.1 Required protocols 

Each of the controller protocols listed in table 14-4 and described in clause 17, shall be 
implemented individually in a controller: 
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Table 14-4 - Required protocols 



Protocol keyword 


Subclause 


RESET 
ALLSPOLL 


17.1 
17.3 



1 4.3.2 Optional protocols 

The controller protocols listed in table 14-5 and described in clause 17, may be 
implemented in a controller: 

Table 14-5 - Optional protocols 



Protocol keyword 


Subclause 


FINDRQS 


17.2 


PASSCTL 


17.4 


REQUESTCTL 


17.5 


FINDLSTN 


17.6 


SETADD 


17.7 


TESTSYS 


17.8 



1 4.4 Functional element handling 

A controller shall have the capability of sending all the IEC 625-2 functional syntactic 
elements described in clause 7. A controller shall have the capability to receive all the 
IEC 625-2 functional syntactic elements described in clause 8. 

14.5 Controller specification requirements 

Information about how the manufacturer implemented controller requirements of this 
standard shall be supplied with the controller documentation by the manufacturer. This 
information shall include: 

1) A list of IEC 625-1 Interface Function subsets implemented, clause 15. 

2) A list of control sequences which can be performed by the controller, see 16.2. 

3) A list of protocols which can be performed by the controller, clause 17. 

4) A description of how the various functional elements are sent and received by the 
controller, see 14.4. 

5) Any buffer size limitations shall be described, see 7.7.6 and 8.7.9. 

6) A description of how timeouts work, see 15.2 and 15.3.2, including: 

- how timeouts are turned on and off, 

- if the timing is done on a byte or message basis, 

- the allowable time values for the timeout. 
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15 IEC 625-2 controller requirements 

15.1 Controller interface function requirements 

This clause describes the IEC 625-1 interface function requirements of a controller. It 
also specifies the additional requirements of a controller that are directly associated with 
the ten IEC 625-1 interface functions. These requirements are intended to supplement the 
IEC 625-1 specification for the instrument system environment as described in this 
standard. 

15.1.1 Controller requirements 

The controller shall have the following Controller function capabilities: system controller 
(C1), send IFC and take charge (C2), send REN (C3), respond to SRQ (C4), send 
interface messages (one of C5-C27), and take control synchronously (one of C5, C7 f C9, 
C11, C13, C15, C17, C19, C21, C23. C25, C27). Receive control (one of C5-C15). pass 
control (one of C5-C11 or C17-C23), pass control to self (one of C5, C7. C17, C19), and 
parallel poll (one of C5, C9, C13, C17, C21, C25) are optional capabilities. 



15.1.2 Talker requirements 

For IEC 625-2 device-specific message transmission, the controller shall contain one of 
the Talker subsets T5-T8 or TE5-TE8. These subsets mandate the basic talker with 
unaddress if MLA. Optional capability includes responding to a serial poll and having a 
talk-only mode. Complete Source Handshake (SH1) capability is also required to support 
the Talker subset. 



15.1.3 Listener requirements 

For IEC 625-2 device-specific message reception, the controller shall contain one of the 
Listener subsets L3-L4 or LE3-LE4. These subsets mandate the basic listener with 
unaddress if MTA with optional capability to contain a listen-only mode. Complete 
Acceptor Handshake (AH1) capability is also required to support the Listener subset. 



1 5. 1 .4 Passing control requirements 

If a controller is expected to execute the protocol described in clauses 17.4 and 17.5 for 
passing and returning control, it shall have the subset capability to 'Pass Control' and 
Take Control Synchronously". That is, subsets C1 , C2, C3 and C4 are required along with 
a choice of either C5, C7, C9 or C11. A controller which can pass control shall also 
contain the T5, T6, TE5, or TE6 Talker function subsets that support serial poll. 



15.1.5 Electrical requirements 

A controller shall implement the E2 electrical interface option (IEC 625-1 , annex C). Open 
collector drivers shall be used to drive the SRQ, NRFD and NDAC signal lines. Three- 
state drivers shall be used to drive the DAV, EOI, ATN, REN, and IFC signal lines. When 
an IEC 625-1 -device in an IEC 625-1 system is not in PPAS, the controller shall use 
three-state drivers to drive the DI01-8 signal lines. If an IEC 625-1 -device in the IEC 625-1 
system is in PPAS, the controller shall use open collector drivers or the high-impedance state 
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of three-state drivers to drive the DI01-8 signal lines as appropriate to the controller's 
current operation. 



15.2 Additional IEC 625-2 controller requirements 
A controller shall have: 

1) a means of providing low-level bus control via application software to allow the user 
independently to: 

- pulse IFC TRUE for greater than 100 ms, 

- set the REN signal line either TRUE or FALSE, 

- send singly or in any combination any interface message defined in IEC 625-1 , 

- send and detect the IEC 625-1 END message {i.e. the EOI signal line TRUE and 
the ATN signal line FALSE handshook with a data byte); 

2) the facility (either directly or via the application program) to input and output the 
codes, formats, protocols, and common commands as defined in this standard; 

3) the facility to sense the state (TRUE or FALSE) of the SRQ line; 

4) the facility to sense FALSE to TRUE SRQ line transitions. Timing of application 
program actions following the transition is beyond the scope of this standard; 

5) the facility (either directly or via the application program) to examine the status byte 
on a bit basis; 

6) the facility to detect the error condition of the controller attempting to source 
handshake a byte while all other devices are in AIDS and relay the error to the 
application program; 

7) the facility to timeout on controller-to-device and device-to-controller message 
exchange and have the ability to relay the occurrence of a timeout to the application 
program. A timeout occurs when a single handshake or a sequence of handshakes 
are not completed within an allocated time. The application program shall be able to 
enable and disable this facility. The controller documentation shall include 
information on how timeouts are controlled. 



15.3 IEC 625-2 controller recommendations 

15.3.1 Monitoring bus lines 

For diagnostic use, controllers may monitor the IEC 625-1 signal lines and report their 
status and/or transitions to the application program. 

If the controller does not implement the SETADD and FINDLSTN common controller 
protocols, the application programmer needs to monitor NRFD and NDAC to perform these 
protocols at the application layer. 



223 



IS 10767 (Part 2): 2001 
I EC 60625-2 (1993) 

15.3.2 Timeouts 

The capability to vary the value of the timeout is recommended. The range and resolution 
is controller dependent, but shall be documented. 

15.3.3 SRQ interrupts 

Subclause 15.2 requires that a controller be able to sense and report FALSE to TRUE 
transitions of SRQ. In addition, a controller may optionally provide a means for an 
application program to branch to a specified section of the application program when SRQ 
changes from FALSE to TRUE. The SRQ servicing routine may delay execution until the 
current message is completely transmitted or received, it may start executing immediately 
after the current data byte is completely transferred, or it may delay execution until a 
convenient time for the controller. 



16 Controller message exchange protocols 

Figure 16-1 contains the logical model of a controller. 
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Figure 16-1 - Controller model 

16.1 Definitions 

16.1.1 IEC 625-1 driver 

This element contains the state machines described in IEC 625-1 . It also controls much of 
the sequencing of remote messages. 

16.1.2 Programming environment 

This block provides capabilities related to sending and receiving messages on the 
IEC 625-1 bus to the application program. This standard describes which capabilities shall 
be supplied to the application program. 
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The programming environment is typically not written by the user or developer of the 
system. It is instead written by the manufacturer or supplier of the controller. An 
operating system and programming language with possibly some extra routines would 
typically comprise a programming environment. 



16.1.3 Application program 

The application program is typically written by the user or developer of the system. This 
program is written to perform a specific task in a limited environment. The purpose or 
description of any application programs is beyond the scope of this standard. 



16.1.4 IEC 625-2 controller 

The controller, described in clause 15, is the combination of the programming 
environment and the IEC 625-1 driver. The application program interfaces with the 
controller to perform IEC 625-1 operations. Many aspects of this combination are beyond 
the scope of this standard. Only those aspects which are needed to ensure reliable 
communication between the application program and devices are specified. 



16.1.5 IEC 625-1 bus signals 

The IEC 625-1 standard describes messages which are transmitted on the bus and 
exchanged between the device and the bus. This element encompasses those messages. 

16.1.6 DAB 
See 6.1.4.2.1 

16.1.7 END 
See 6.1 .4.2.2 

16.1.8 Control sequence 

Control sequences are requests to send IEC 625-1 remote messages. Control sequences 
put the state machines in both the controller and devices into certain desired states. 



16.1.9 Addresses 

Addresses refer to talk and listen addresses of devices and controllers on the bus. 
Addresses are always parameters to a control sequence. 



An address has two components. The first component is the primary address and the 
second component is the secondary address. If the second component is null (a zero 
secondary address is not null) only the primary address is used. 

A controller shall provide the user with the capability to send only primary addresses as 
well as the capability to send both primary and secondary addresses (extended 
addressing). 
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This standard places no requirements on how addresses are passed from the application 
program to the controller. The controller may require that the application program supply 
the address explicitly with every request to transfer a message. Alternatively, a data 
structure may exist which allows a very sophisticated method of determining an address. 
Many techniques exist, and may be used, to generate addresses within the controller. 



In general, passing the entire seven bits of a complete primary or secondary address is 
not necessary. A number between and 30 could be passed along with the information 
that it is either a talk, listen, or secondary address. 

16.1.10 IEC 625- 1 state conditions 

The IEC 625-1 driver contains state machines described in IEC 625-1 . State conditions 
are indications of which states the state machines are in at any given time. The operating 
system or programming language occasionally needs to interrogate the current state 
conditions to be sure messages are being reliably transferred. 



16.1.11 Data messages 

Data messages are either <PROGRAM MESSAGE> or <RESPONSE MESSAGE> 
functional elements. 

16.1.11.1 <PROGRAM MESSAGE> 

A <PROGRAM MESS AG E> is a sequence of data bytes which is transferred from the 
controller to a device with ATN FALSE. The meaning of a <PROGRAM MESSAGE> is, in 
general, device-specific (see clause 7). 

16.1.11.2 <RESPONSE MESSAGE> 

A <RESPONSE MESSAGE> is a sequence of data bytes which is transferred from the 
device to the controller with ATN FALSE. The meaning of a <RESPONSE MESSAGE> is, 
in general, device-specific (see clause 8). 

16.1.12 Controller errors 

Controller errors are indications to the application program that the controller was 
unable to completely perform a request from the application program. 



1 6.2 Control sequences 

Control sequences send one or more IEC 625-1 remote messages. This standard 
describes those sequences which are known to be valuable to application programmers. 
Additional sequences may also be made available to the application program which are 
beyond the scope of this standard. 

Some control sequences are combinations of other control sequences. If a controller 
supplies a control sequence which is the combination of several other control sequences, 
the controller shall also supply the subordinate control sequences individually. 
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1 6.2. 1 SEND COMMAND 



The SEND COMMAND control sequence allows the application program to send an 
arbitrary sequence of ATN-true commands. This control sequence allows the user to 
construct control sequences which are not described in this standard or which may not be 
supplied with the controller. 

One or more 7-bit commands shall be passed with the SEND COMMAND control 
sequence. The IEC 625-1 driver shall: 

set ATN TRUE and EOI FALSE 
FOR each command passed 

send the command with DI08 FALSE 
NEXT command 

ATN shall be held TRUE and EOI held FALSE until another control sequence makes them 
change. 

16.2.2 SEND SETUP 

The SEND SETUP control sequence configures the system bus so that a <PROGRAM 
MESS AG E> can be transferred from the controller to a device. It is also used in some 
other control sequences. 

One or more listen addresses shall be passed with the SEND SETUP control sequence. 
The IEC 625-1 driver shall: 

set ATN TRUE and EOI FALSE 
send the controller's talk address 
send the IEC 625-1 unlisten message (UNL) 
FOR each listen address passed 

send the listen address 
NEXT listen address 

ATN shall be held TRUE and EOI held FALSE until another control sequence makes them 
change, 

16.2.3 SEND DATA BYTES 

The SEND DATA BYTES control sequence is used to transfer DABs from a controller to a 
device. 

No addresses are passed with the request to perform a SEND DATA control sequence. 
The application program shall, however, pass a list of zero or more DABs and a 
terminator. The IEC 625-1 driver shall: 

set ATN FALSE 

FOR each data byte passed 

send a data byte 
NEXT data byte 
send the terminator 

NOTE - If the terminator is the END message, the terminator is actually sent with the last data byte and not 
separately. If the terminator is the END message and no bytes are passed, the controller shall indicate an 
error to the application program. 
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ATN shall remain FALSE while the data bytes and terminator are transferred. 



At the completion of the sequence, ATN is FALSE and all currently addressed devices 
remain addressed. 

IEC 625-2 <PROGRAM MESSAGE> elements (see clause 7) are commonly terminated by 
NL with END. A controller shall provide a means for the application program to send an 
IEC 625-1 device-specific message without having first specified a message terminator. If 
the application program has not specified a terminator, the controller shall send NL with 
END as the terminator. A controller is also required to have the capability to send END 
with the last DAB as a terminator. The controller may also allow the application program 
to select alternative terminators. 



At least four useful terminators exist: 

1) NL with END - required 

This terminator is the typical <PROGRAM MESSAGE TERMINATOR> (see 7.5). 

2) send the last DAB with END - required 

This terminator allows messages to be sent to IEC 625-1 devices which terminate 
only on the END message. 

3) null i.e. send nothing - required 

The null terminator allows a single message to be sent in pieces via multiple SEND 
DATA BYTES. 

4) send one or more application program supplied special characters (e.g. NL or CR 
LF) without END - optional 

This terminator allows messages to be sent to non-lEC 625-2 devices which may 
attach a special significance to the END message. 

When sending data messages to devices, the application program should use the first 
alternative. 

16.2.4 SEND 

The SEND control sequence is used to transfer a complete <PROGRAM MESSAGE> from 
a controller to a device. 

One or more listen addresses shall be passed with the SEND control sequence. A list of 
one or more data bytes and a terminator shall also be passed. The method of passing the 
required information is purposely left unspecified. The terminator shall default to NL with 
END. 



The IEC 625-1 driver shall: 

execute a SEND SETUP 

with the supplied listen addresses 

execute a SEND DATA BYTES 

with the supplied data bytes and terminator 
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16.2.5 RECEIVE SETUP 



The RECEIVE SETUP control sequence configures the system bus so that a 
<RESPONSE MESSAGE> can be transferred from a device to the controller. It is also 
used in some other control sequences. 

A single talk address shall be passed with the RECEIVE SETUP control sequence. The 
IEC 625-1 driver shall: 

set ATN TRUE and EOI FALSE 
send the IEC 625-1 unlisten message (UNL) 
send the controller's listen address 
send the supplied talk address 

ATN shall be held TRUE and EOI held FALSE until another control sequence makes them 
change. 

1 6.2.6 RECEIVE RESPONSE MESSAGE 

The RECEIVE RESPONSE MESSAGE control sequence is used to transfer data bytes 
from a device to a controller. 

No addresses are passed with the request to perform a RECEIVE RESPONSE MESSAGE 
control sequence. The controller shall be passed a stop-handshaking condition either as 
a default condition or explicitly. The programming environment shall provide a means of 
transferring the received information to the application program. The controller may 
transform or separate the data bytes into a form more readily usable by the application 
program. For example, a sequence of digits could be converted into the internal 
representation of a number. 



The controller shall continue to handshake data bytes until the specified stop- 
handshaking condition occurs. The controller shall not handshake any data bytes after 
the stop-handshaking condition until the application program initiates another request to 
receive data. The IEC 625-1 driver shall: 



set ATN FALSE 

UNTIL stop-handshaking condition 

receive data bytes 
END UNTIL 

ATN shall remain FALSE while the data bytes are transferred. 

At the completion of the sequence, ATN is FALSE and all currently addressed devices 
remain addressed. The controller shall keep NRFD and NDAC TRUE until another control 
sequence is executed. 

Atypical stop-handshaking condition for RECEIVE RESPONSE MESSAGE is receiving the 
END message. A controller shall provide the capability to stop-handshaking on the END 
message. 
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Alternate stop-handshaking conditions shall be provided which can be selected by the 
application program. Several ways of stopping the reception of data exist: 

1) Stop only on END - required 

Works with all I EC 625-2 devices and many non-lEC 625-2 devices. 

2) Stop on NL - required 

Allows the controller to terminate on the NL at the end of a <RESPONSE 
MESSAGE>. Also included for compatibility with devices which do not adhere to 
IEC 625-2. 

3) Stop on comma - required 

Allows the controller to receive <RESPONSE DATA> elements on an individual 
basis. 

4) Stop on semicolon - required 

Allows the controller to receive <RESPONSE MESSAGE UNIT> elements on an 
individual basis. 

5) Stop on a byte count - optional 

May be useful in receiving <DEFINITE LENGTH ARBITRARY BLOCK RESPONSE 
DATA>. 

6) Stop on an arbitrary DAB match - optional 

Included to allow controllers to stop-handshaking at the end of responses from 
devices which do not follow IEC 625-2 and thus may use unknown methods to 
terminate a response message. 

7) Stop at end of <RESPONSE HEADER> or <RESPONSE DATA> - optional 

For example, any of the following: 

<RESPONSE HEADER SEPARATOR^ 
<RESPONSE DATA SEPARATOR:*. 
<RESPONSE MESSAGE UNIT SEPARATOR^ 
<RESPONSE MESSAGE TERMINATOR>. 

8) Stop on end of <RESPONSE MESSAGE DATA ELEMENT> - optional. 

For example, any of the following: 

<RESPONSE MESSAGE DATA SEPARATOR^ 
<RESPONSE MESSAGE UNIT SEPARATOR^ 
<RESPONSE MESSAGE TERMINATOR>. 

9) Stop on end of <RESPONSE MESSAGE UNIT> - optional. 

For example, any of the following: 

<RESPONSE MESSAGE UNIT SEPARATOR^ 
<RESPONSE MESSAGE TERMINATOR>. 

Implementation of options 7, 8, and 9 is recommended, as they allow an application 
program to easily identify the syntactic components of a <RESPONSE MESSAGE>. 
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A controller designer may choose to allow various combinations of conditions to generate 
the stop-handshaking condition. For example, the stop-handshaking condition could be NL 
or END, NL or semicolon, etc. This iist is not intended to restrict the controller from 
supplying additional techniques for stopping the handshaking process. 

NOTE - Alternatives 7, 8, and 9 require the controller to parse the received message in order to detect the 
stop-handshaking condition. 

16.2.7 RECEIVE 

The RECEIVE control sequence is used to transfer a <RESPONSE MESSAGE> from a 
device to a controller. 

A single talk address and a stop-handshaking condition shall be passed with the RECEIVE 
control sequence. The application program shall also provide internal storage for the 
received data bytes. The I EC 625-1 driver shall: 



execute a RECEIVE SETUP 

with the supplied talk address 
execute a RECEIVE RESPONSE MESSAGE 

with the supplied stop-handshaking condition 



16.2.8 SENDIFC 

The SEND IPC control sequence can only be executed by the system controller. The effect 
of the control sequence is to remove all talkers and listeners, serial poll disable all 
devices, and return control to the system controller. At power-on, the controller shall 
execute the SEND IPC control sequence. 



When the application program requests that the SEND IFC control sequence be executed, 
the IEC 625-1 driver shall: 

pulse the IEC 625-1 bus signal IFC TRUE for more than 
1 00 \xs 
(see 15.3.16 of (EC 625-1). 

The state of the other IEC 625-1 bus lines shall not change. The controller shall not 
execute any other control sequences until IPC has been made FALSE by this control 
sequence. 

16.2.9 DEVICE CLEAR 

The DEVICE CLEAR control sequence is used to send the dcas message and place all or 
selected devices in DCAS (Device Clear Active State). The behaviour of a device in 
DCAS is well defined (see 5.8). The DEVICE CLEAR control sequence should be used as 
part of the initialization of a system (see 17.1). 
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After completion of the DEVICE CLEAR control sequence the DIO lines may be left in any 
state convenient for the controller. ATN shall remain TRUE at the end of the control 
sequence. The EOI line shall remain FALSE during and at the completion of the DEVICE 
CLEAR control sequence to avoid performing parallel polls. 



16.2.9.1 Selected Device(s) 

If the application program passes an address(es) with a request to send the DEVICE 
CLEAR control sequence, the IEC 625-1 driver shall: 



execute a SEND SETUP 

with the supplied addresses 
send the IEC 625-1 Selected Device Clear message (SDC) 

16.2.9.2 All devices 

If the application program requests that the DEVICE CLEAR control sequence be sent and 
no addresses are also passed, the IEC 625-1 driver shall: 



set ATN TRUE 

send the IEC 625-1 Device Clear message (DCL) 

16.2.10 ENABLE LOCAL CONTROLS 

The ENABLE LOCAL CONTROLS control sequence is used to place either all or selected 
devices into a local state (LOCS or LWLS). See 5.6 for a discussion on how devices 
behave after a transition from a remote to a local state and while in a local state. 



16.2.10.1 Selected devlce(s) 

If the application program passes an address(es) with a request to execute the ENABLE 
LOCAL CONTROLS control sequence, the IEC 625-1 driver shall: 



execute a SEND SETUP 

with the supplied addresses 
send the IEC 625-1 "go to local" message (GTL). 

After completion of the ENABLE LOCAL CONTROLS control sequence for selected 
devices, the DIO lines may be left in any state convenient for the controller and ATN 
shall remain TRUE. The EOI line shall remain FALSE during and at the completion of the 
ENABLE LOCAL CONTROLS control sequence to avoid performing parallel polls. 
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16.2.10.2 All devices 



If the application program requests that the ENABLE LOCAL CONTROLS control 
sequence be sent and no addresses are also passed, the IEC 625-1 driver shall: 

set the IEC 625-1 signal REN FALSE 

{enter the C interface function system control remote 
not active state, see 15.3.18 of IEC 625-1). 



The state of the other IEC 625-1 bus lines shall not change. 

1 6.2. 1 1 ENABLE REMOTE 

The ENABLE REMOTE control sequence allows the application program to put the 
IEC 625-1 system or selected devices into a remote state. This sequence is a companion 
to the ENABLE LOCAL CONTROLS control sequence. 



16.2.11.1 Selected device(s) 

If the application program passes an address(es) with the request to send the ENABLE 
REMOTE control sequence, the IEC 625-1 driver shall: 

IF REN is FALSE 

THEN wait until REN has been FALSE at 

least 100 us 
set the IEC 625-1 signal line REN TRUE 
execute a SEND SETUP 

with the supplied addresses 

16.2.11.2 All devices 

If the application program does not pass an address with the request to send the REMOTE 
control sequence, the controller shall: 

IF REN is FALSE 

THEN wait until REN has been FALSE at 

least 100 us 
set the IEC 625-1 signal line REN TRUE. 

The state of the other IEC 625-1 bus lines shall not change. Note that merely making REN 
TRUE does not make a device change states. The device must later be addressed to 
listen before it will enter one of the remote states (REMS or RWLS). 



16.2.12 SET RWLS 

The SET RWLS control sequence allows the application program to disable the return to 
local (rtl) local message in one or more devices. Selected devices are put into RWLS. 
Devices not currently addressed to listen are put into LWLS by this control sequence. 
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One or more listen addresses are passed with a request to send the SET RWLS control 
sequence. The IEC 625-1 driver shall: 

execute an ENABLE REMOTE 

with the supplied listen addresses 
send the IEC 625-1 local lockout message (LLO) 

After completion of the SET RWLS control sequence, the DIO lines may be left in any 
state convenient for the controller. The ATN line shall remain TRUE and the EOI line 
FALSE until another control sequence changes them. 

16.2.13 SEND LLO 

The SEND LLO control sequence allows the application program to put all the devices on 
the bus which are in LOCS into LWLS. Any device which happened to be in LADS when 
this control sequence is executed will actually be put into RWLS. 

No addresses are passed with the request to perform a SEND LLO control sequence. The 
IEC 625-1 driver shall: 

execute an ENABLE REMOTE without addresses 

set ATN TRUE and EOI FALSE 
send the IEC 625-1 local lockout message (LLO) 

After completion of the SEND LLO control sequence, the DIO lines may be left in any state 
convenient for the controller. The ATN line shall remain TRUE and the EOI line FALSE 
until another control sequence changes them. 

16.2.14 PASS CONTROL 

The PASS CONTROL control sequence allows the application program to give control of 
the system bus to a device. A protocol is provided in 17.4 for transferring control. 



The application program shall pass a talk address whenever it requests the controller to 
execute the PASS CONTROL control sequence. The IEC 625-1 driver shall: 



execute a RECEIVE SETUP 

with the supplied talk address 
send the IEC 625-1 take control message (TCT) 
set ATN FALSE 

NOTE - Control is passed as a consequence of the IEC 625-1 C function protocol. Handshaking the TCT 
causes the controller passing control to enter CIOS. ATN going false then causes the receiving controller to 
enter CACS, become active and assert ATN. 



16.2.15 PERFORM PARALLEL POLL 

The PERFORM PARALLEL POLL control sequence allows the application program to 
perform a parallel poll on the system bus. 
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No addresses are passed with the request to perform a PERFORM PARALLEL POLL 
control sequence. The application program shall, however, supply a storage location for 
the resulting parallel poll response, PPR, message. When the application program 
requests that a PERFORM PARALLEL POLL control sequence be sent, the IEC 625-1 
driver shall: 



set ATN TRUE and EOI TRUE 

read and store the resulting PPR message in 

the supplied storage location 
send rpp local message FALSE 

16.2.16 PARALLEL POLL CONFIGURE 

The PARALLEL POLL CONFIGURE control sequence allows the application program to 
configure the parallel poll response from a device. The device being configured must 
have IEC 625-1 PP1 capability. 

The application program shall pass an address, the DIO line to be driven, and the sense of 
the driven line with the request for a PARALLEL POLL CONFIGURE control sequence. An 
appropriate parallel poll enable message is constructed from the information about which 
tine is to be driven and the sense of the driven line. The IEC 625-1 driver shall: 



execute a SEND SETUP 

with the supplied address 
send the IEC 625-1 parallel poll configure message (PPC) 
send the IEC 625-1 parallel poll enable message (PPE) 

At the completion of the control sequence ATN shall remain TRUE and EOI shall remain 
FALSE until changed by another control sequence. 

1 6.2. 1 7 PARALLEL POLL UNCONFIGURE 

The PARALLEL POLL UNCONFIGURE control sequence provides a means to keep all or 
selected devices from responding to a parallel poll. 



At the completion of the control sequence ATN shall remain TRUE and EOI shall remain 
FALSE until changed by another control sequence. 

16.2.17.1 Selected devlce(s) 

If the application program passes an address(es) with the request to send the PARALLEL 
POLL UNCONFIGURE control sequence, the IEC 625-1 driver shall: 



execute a SEND SETUP 

with the supplied addresses 
send the IEC 625-1 parallel poll configure message (PPC) 
send the IEC 625-1 parallel poll disable message (PPD) 

with the lower four bits as zeros 
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16.2.17.2 All devices 

If the application program does not pass an address with the request to send the 
PARALLEL POLL UNCONFIGURE control sequence, the IEC 625-1 driver shall: 



set ATN TRUE 

send the IEC 625-1 parallel poll unconfigure message (PPU) 



16.2.18 READ STATUS BYTE 

The READ STATUS BYTE control sequence provides a means of reading the status byte 
from a specific device. 

A single talk address shall be passed with the request. The controller shall provide a 
storage location for the status byte. When the application program requests the controller 
to send the READ STATUS BYTE control sequence, the IEC 625-1 driver shall: 



set ATN TRUE and EOI FALSE 

send the IEC 625-1 uniisten message (UNL) 

send the controller's listen address 

send the IEC 625-1 serial poll enable message (SPE) 

send the talk address 

set ATN FALSE 

handshake a data byte 

store the status byte and RQS message 

set ATN TRUE 

send the IEC 625-1 serial poll disable message (SPD) 

send the IEC 625-1 untalk message (UNT) 



At the completion of the control sequence ATN shall remain TRUE and EOI shall remain 
FALSE until changed by another control sequence. At no time during the control sequence 
shall the controller set EOI TRUE. The controller shall ignore the state of the EOI line 
while handshaking the data byte. 



16.2.19 TRIGGER 

The TRIGGER control sequence provides a way to send the IEC 625-1 group execute 
trigger message to specific devices or to all the devices which are currently addressed to 
listen. 

At the completion of the control sequence ATN shall remain TRUE and EOI shall remain 
FALSE until changed by another control sequence. 
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16.2.19.1 Selected device(s) 



If the application program passes an address(es) with the request to send the TRIGGER 
control sequence, the IEC 625-1 driver shall: 



execute a SEND SETUP 

with the supplied addresses 
send the IEC 625-1 group execute trigger message (GET) 

16.2.19.2 All addressed devices 

If the application program does not pass an address with the request to send the 
TRIGGER control sequence, the IEC 625-1 driver shall: 

set ATN TRUE 

send the IEC 625-1 group execute trigger message (GET) 

NOTE - If a TRIGGER control sequence is executed and no devices are currently addressed to listen, no 
device will be triggered. All devices on the bus will handshake the GET message, but only those which are 
currently addressed to listen and have 0T1 capability will process the message. 
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17 Common controller protocols 

This clause describes protocols which are executed by the controller in a system. These 
protocols make use of required capability and occasionally optional capability which is 
described in this standard. The protocols are generally designed to work in mixed systems 
consisting of both devices and non-lEC 625-2 devices. This standard attempts to point out 
special considerations may have to be observed when operating in a system containing 
both devices and non-lEC 625-2 devices. Special considerations listed in this section 
should not be thought of as exhaustive. 



Many of the protocols require that information be passed from or to the protocol. The 
mechanism for passing this information is intentionally left unspecified. The particular 
technique used for passing information is left to the controller designer's discretion. 



Each protocol described in this section has a keyword associated with it. Controller 
manufacturers and designers are encouraged to use this keyword in the controller's 
documentation. Each protocol has an associated controller algorithm. A controller shall 
implement a functionally equivalent routine for this algorithm when implementing the 
protocol. Some of the constructs used in describing the algorithm may not be directly 
available in the controller. The controller may also have constructs which are superior to 
the ones used in the description of the algorithm. 



Table 17-1 lists all the common controller protocols defined in this standard. 



Table 17-1 - IEC 625-2 common controller protocols 



Keyword 


Name 


Subclause 


Compliance 


RESET 


Reset 


17.1 


Mandatory 


FINDRQS 


Find Device Requesting 
Service 


17.2 


Optional 


ALLSPOLL 


Serial Poll All Devices 


17.3 


Mandatory 


PASSCTL 


Pass Control 


17.4 


Optional 


REQUESTCTL 


Request Control 


17.5 


Optional 


FINDLSTN 


Find Listeners 


17.6 


Optional 


SETADD 


Set Address 


17.7 


Optional, but 
requires FINDLSTN 


TESTSYS 


Self-Test System 


17.8 


Optional 



17.1 Reset protocol 
17.1.1 Keyword 
RESET 
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17.1.2 Purpose 

The reset protocol is used to initialize an entire system using three levels. 

Bus initialization 

The first level of reset places the system bus into an idle condition. All devices are 
unaddressed and put into a serial poll idle state. The system controller becomes controller- 
in-charge. 

Message exchange initialization 

The second level of reset ensures that a device can be sent a <PROGRAM MESSAGE>. 
See 5.8. 

Device initialization 

The third level of reset initializes device-specific functions within a device. See 10.32. 

17.1.3 Information requested by the protocol 

This protocol requires a list of the addresses of all the devices in the system. 

17.1.4 Information supplied by the protocol 
Nothing is returned by the protocol. 

17.1.5 Controller algorithm 

A complete system reset is accomplished by doing all three levels of reset, in order, to 
every device. 

Bus initialization 

The controller shall execute an ENABLE REMOTE control sequence (see 16.2.11.2) with 
no addresses. The controller shall then execute a SEND IFC control sequence, 
see 16.2.8. 

Message exchange initialization 

The DEVICE CLEAR control sequence is executed without addresses. This control 
sequence sends a universal Device Clear. See 16.2.9.2. 

Device initialization 

The controller shall execute a SEND control sequence with the supplied addresses and 
the TERMINATED PROGRAM MESSAGE>: 

*RST<PMT> 
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17.1.6 Additional requirements and guidelines 

Under different circumstances, each level of reset may be done individually or in 
combination with other levels. If several levels are to be done together, bus initialization 
should be performed before message exchange initialization, and message exchange 
initialization should be performed before device initialization. Specification of all possible 
combinations is beyond the scope of this standard. 

Warning: Devices which do not comply with IEC 625-2 may behave much differently 
from what is described in this protocol for message exchange and device initialization. 
A bus initialization, IFC, should behave identically on all IEC 625-1 devices. The 
behaviour of non-lEC 625-2 devices should be investigated before doing message 
exchange initialization with them. A device initialization should never be done to a 
device which has not implemented the *RST command. 

17.1.7 Standard compliance 

The RESET common controller protocol shall be supplied in all controllers. 



1 7.2 Find device requesting service protocol 

17.2.1 Keyword 
FINDRQS 

17.2.2 Purpose 

The purpose of the FINDRQS protocol is to find a device which is requesting service and 
to return its status byte. 

1 7.2.3 Information requested by the protocol 

A list containing the address of every device which can request service must be supplied 
in the order in which they should be polled. A device with IEC 625-1 SR1 capability must 
be at every address in the list. 

The list may be explicitly passed to the protocol or may reside in a common area. This 
protocol need only know where to find the address list. 

17.2.4 Information supplied by the protocol 

When the protocol has completed successfully, the address of the first device in the list 
requesting service and its status byte are returned. If not successful, an error message is 
returned. 
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17.2,5 Controller algorithm 



The protocol is initiated when SRQ is sensed TRUE. The application program may test the 
SRQ line and then invoke the protocol, or the controller may automatically initiate the 
protocol when SRQ is true. The time from SRQ becoming TRUE to the initiation of this 
protocol is intentionally unspecified. 

Initialize pointer to top of address list 

Assert ATN TRUE 

Send IEC 625-1 UNL remote message 

Send controller's LAG 

Send IEC 625-1 SPE remote message 

REPEAT 

Send TAG of address pointed to 

Set ATN FALSE 

Handshake a DAB (STB and RQS) 

Advance pointer 

Set ATN TRUE 
UNTIL RQS is true or pointer is past the end of the address list 
Send IEC 625-1 SPD remote message 
Send IEC 625-1 UNT remote message 
IF RQS is TRUE 

THEN return last address sent 
return last status byte received 

ELSE return error 

1 7.2.6 Additional requirements and guidelines 

The ordering of the addresses in the list is important. The device which requires the most 
rapid servicing should have its address at the top of the list. 

The protocol cannot serial poll all possible IEC 625-1 addresses for at least two reasons. 
First, serial polling an address which does not have IEC 625-1 SR1 capability may cause 
the handshake never to be completed. Second, the time required to poll all the primary 
addresses and secondary addresses is prohibitively long even if timeouts are used. 

Certain precautions must be taken to ensure reliable performance of this protocol. 

The service request interface function in IEC 625-1 allows a device to change the SRQ 
remote message sent without receiving any other remote messages. If a device changes 
its rsv message from TRUE to FALSE during the execution of the protocol, an error may 
be generated. Devices are constrained not to remove the local rsv message until specific 
remote messages are received. If the FINDRQS is initiated by an interrupt, multi-tasking 
operating systems need to be told which task is to be passed the information obtained by 
this protocol. 

At the completion of this protocol, all devices will be unaddressed. An error will occur in 
the application program if devices are expected still to be addressed when control is 
returned from the protocol. 
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This protocol makes no provision for the case when the address of a device is included in 
the list which does not have SR1 capability. If the device has T3, T4, T7, or T8 capability, 
the device may source handshake a data byte from its normal output queue. DIO 7 in this 
byte has no relation to RQS. If the device has SHO or TO capability or has nothing to say 
when it is addressed to talk, the device will never source handshake a data byte, and this 
protocol will never complete unless a timeout is implemented. 



17.2.7 Standard compliance 

The FINDRQS common controller protocol may optionally be supplied in controllers. 

1 7.3 Serial Poll All Devices protocol 

17.3.1 Keyword 
ALLSPOLL 

17.3.2 Purpose 

The purpose of the ALLSPOLL protocol is to read the status byte of every device with SR1 
capability in the system. 

1 7.3.3 Information requested by the protocol 

A list containing the address of every device which has SR1 capability should be supplied 
to the protocol. The ordering of the addresses in the list is not important. A device with 
IEC 625-1 SR1 capability should be at every address in the list. Storage locations for all 
the status bytes to be read must also be supplied. 

The list may be explicitly passed to the protocol or may reside in a common area. This 
protocol must only know where to find the list of addresses. 

1 7.3.4 Information supplied by the protocol 

When the protocol has completed successfully, the status byte of every device is 
available. The status bytes shall be stored in such a way that the application program can 
associate a particular status byte with an address. 

17.3.5 Controller algorithm 

The protocol may be initiated at any time by the application program. The sense of SRQ 
when the protocol is invoked is unimportant. 

Initialize pointer to top of address list 

Initialize status byte list 

Set ATN TRUE 

Send IEC 625-1 UNL remote message 

Send controller's LAG 

Send IEC 625-i SPE remote message 

WHILE pointer is not past the end of the address list 

Send TAG of address pointed to 

Set ATN FALSE 
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Handshake a DAB (STB and RQS) 

Store the STB and RQS in the status byte list 

Advance pointer 

Set ATN TRUE 
END WHILE 

Send IEC 625-1 SPD remote message 
Send IEC 625-1 UNT remote message 



1 7.3.6 Additional requirements and guidelines 



The protocol cannot serial poll all possible IEC 625-1 addresses for at least two reasons. 
First, serial polling an address which does not have IEC 625-1 SR1 capability may cause 
the handshake never to be completed. Second, the time required to poll all the primary 
addresses and secondary addresses is prohibitively long even if timeouts are used. 



The service request interface function in IEC 625-1 allows a device to send multiple STBs 
while in SPAS. This protocol will only read the first one. 



At the completion of this protocol, all devices will be unaddressed. An error will occur in 
the application program if devices are expected still to be addressed when control is 
returned from the protocol. 

This protocol makes no provision for the case when the address of a device is included in 
the list which does not have SR1 capability. If the device has T3, T4 t T7, or T8 capability, 
the device may source handshake a data byte from its normal output queue. DIO 7 in this 
byte has no relation to RQS. If the device has SRO or TO capability or lias nothing to say 
when it is addressed to talk, the device will never source handshake a data byte, and this 
protocol will never complete unless a timeout is implemented. 



17.3.7 Standard compliance 

The ALLSPOLL common controller protocol shall be supplied in all controllers. 

17.4 Pass control protocol 

17.4.1 Keyword 
PASSCTL 

17.4.2 Purpose 

The purpose of this protocol is to pass control among the devices which have controller 
capability and need to be controller-in-charge. 

17.4.3 Information requested by the protocol 

The protocol requires the address of a device which is currently requesting control of the 
bus. The protocol must also have the address of the controller executing the protocol. 



243 



IS10767(Part2):2001 
IEC 60625-2 (1993) 

1 7.4.4 Information supplied by the protocol 

The address of the device which was passed control is maintained by this protocol. 

1 7.4.5 Controller algorithm 

IF using primary addressing only 
THEN 

Execute SEND control sequence with 

*PCB(SP)<NR1> as the <PROGRAM MESSAGE> 
and NL A END as the terminator. 
(*NR1 is the primary listen address of the 
device which may request control.*) 
ELSE ('using primary and secondary addressing*) 
Execute SEND control sequence with 

*PCB(SP)<NR1>,<NR1> as the <PROGRAM MESSAGE> 
and NL A END as the terminator. 
(*first NR1 is the primary listen address and 
the second NR1 is the secondary address of the 
device which may request control.*) 
Execute PASS CONTROL used as a control sequence with the talk address of 
device requesting control. 

When the device no longer requires control of the bus, it shall pass control to a controller 
using a PASS CONTROL control sequence with the address it received with the *PCB 
command. See 10.21 and 16.2.14 for details of the *PCB command. 

17.4.6 Additional requirements and guidelines 

When sending its address using the *PCB command, a controller shall send integers in 
the range to 30 in the primary address field and integers in the range to 30 in the 
secondary address field. If no secondary addressing is to be used when passing control 
back, the second parameter shall be omitted. 



The controller-in-charge is responsible for determining when a device is requesting 
control of the system bus. The request control bit in the Standard Event Status Register 
may be enabled to cause an SRQ, so the controller may use SRO to look for a device 
requesting control. Alternatively, the controller may periodically read the Standard Event 
Status Register to determine if a device is requesting control. 



The system controller may use a SEND IFC control sequence to regain control of the 
system bus. This method of gaining control should only be used when an error condition 
is known to exist. 

The current controller-in-charge, even if it is not the controller, may send the *PCB 
command to another potential controller-in-charge. The current controller-in-charge may 
then pass control in a linked list structure. 
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Many possibilities for passing control among several controllers on the same bus exist. An 
attempt to identify all the possible techniques of passing control in such a system is 
beyond the scope of this standard. 



17.4.7 Standard compliance 

The PASSCTL common controller protocol may optionally be supplied in controllers. 

17.5 Requesting control 

17.5.1 Keyword 
REQUESTCTL 

17.5.2 Purpose 

The purpose of this protocol is to allow a potential controller-in-charge to indicate the need 
for control to the current controller-in-charge, to receive the control, and then relinquish 
that control when it no longer requires control of the system bus. The protocol may be 
included in devices which have controller capability. 

17.5.3 Information requested by the protocol 
None 

1 7.5.4 Information supplied by the protocol 
None 

17.5.5 Controller algorithm 

The component (device or controller) requesting to be controller-in-charge asserts its 
Request Control bit TRUE in its Standard Event Status Register to invoke the protocol. 

The current controller-in-charge detects the request in the component's Standard Event 
Status Register either as a result of an SRQ indication by the component or by a polling 
routine and executes the PASSCTL controller protocol sequence. In this sequence, it 
sends its address (or the address of another component) to which the requesting 
component is later to pass control. It then passes control to the requesting component. 



The requesting component stores the address it received to which it is to pass control and 
then accepts control. It sends/receives messages on the bus until it is ready to relinquish 
control. The component then executes a PASSCTL control sequence to relinquish control 
to the component designated by the stored address'. 

The component to receive control participates in the PASSCTL control sequence and 
gains control of the bus. 

17.5.6 Additional requirements and guidelines 

A device which does not have controller capability shall not request control. A device with 
controller capability is required (see 4.8) to have the capability to pass control. 
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The current controller-in-charge, even if it is not the controller, may send the *PCB 
command to another potential controller-in-charage, The current controller-in-charge may 
then pass control in a linked list structure. 

Many possibilities for passing control among several controllers on the same bus exist. 
Attempting to identify all the possible techniques of passing control in such a system is 
beyond the scope of this standard. 

17.5.7 Standard compliance 

The REQUESTCTL common controller protocol may optionally be supplied in controllers. 



17.6 Find Listeners protocol 

17.6.1 Keyword 
FINDLSTN 

17.6.2 Purpose 

The Find Listeners protocol identifies each IEC 625-1 address at which at (east one 
listener device resides. 

1 7.6.3 Information supplied to the protocol 

This protocol requires a list of primary addresses which are to be searched. 

17.6.4 Information supplied by the protocol 

This protocol returns a list of primary addresses, and if extended addresses exist, 
primary/secondary address pairs at which devices reside. 

17.6.5 Controller algorithm 

BEGIN Find Listeners 
WHILE a primary address remains unsent in the address input list 
BEGIN 
Send the IEC 625-1 Unlisten message (UNL) 
Send the LAG of the primary address 
Set ATN FALSE 
Wait 1 MILLISEC minimum 
IFNDACisTRUE 
THEN 
Place primary address in output address list 

fcLofc 
BEGIN 
Send all secondary addresses 
Set ATN FALSE 
Wait 1 MILLISEC minimum 
IF NDAC is TRUE 
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THEN 
BEGIN 
Send the IEC 625-1 Unlisten message (UNL) 
Send the LAG of the primary address 
WHILE a secondary address has not been tested 
BEGIN 
Send an untested secondary address 
Set ATN FALSE 
Wait 1 MILLISEC minimum 
IF NDAC is TRUE 
THEN 
BEGIN 
Put extended address in output list 
Send the IEC 625-1 Unlisten message (UNL) 
Send the LAG of the primary address 
END 
END 
END 
END 
END 
Send the IEC 625-1 Unlisten message (UNL) 
END Find Listeners 

1 7.6.6 Additional requirements and guidelines 

The 1 MILLISEC wait time may not be sufficient for some devices because the time to 
enter AIDS (Acceptor Idle State) of the Acceptor Handshake Function is not specified in 
IEC 625-1. 

This protocol will not work properly in systems containing talk and/or listen-only devices. 
For example, some bus analyzers and bus extenders appear as listen-only devices which 
will cause the protocol to indicate that every address is occupied. 



1 7.6.7 Standard compliance 

The FINDLSTN common controller protocol may be optionally supplied in a controller. 

17.7 Set Address protocol 
17.7.1 Keyword 
SETADD 
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1 7.7.2 Purpose 

The purpose of this protocol is to detect address-configurable devices (those 
implementing the *AAD common command) and to assign these devices primary listen or 
extended listen addresses in accordance with the information given by a user-supplied 
configuration table. 

1 7. 7.3 Information requested by the protocol 

This protocol requires a list of addresses to be searched and a configuration table. The 
table shall contain a set of entries in which each entry has a set of fields consisting of a 
manufacturer, model number, serial number and the listen address to be assigned. An 
entry is allowed to have empty fields. 

1 7.7.4 Information supplied by the protocol 

This protocol supplies an updated configuration table of those devices detected in the 
address space given in the input address list, and error status. 

17.7.5 Controller algorithm 

NOTES 

1 Four fields are searched as shown below. The first three fields are identical to the associated fields of 
the *IDN? response. The fourth is determined by the device's current address. 

Manufacturer 

Model Number 

Serial Number 

Current Primary or Extended Listen Address 

2 All data bytes are sent to the system bus with DI08 FALSE unless otherwise specified. 

3 The primary listen address assigned by this protocol is sent as a single data byte having a decimal 
value in the range 32 to 62. The secondary address is sent as a data byte in the range of 96 to 126. A 
primary or extended address is referred to as a listen address in this protocol. 

17.7.5.1 Set Address procedure 
BEGIN Set-Address 

Mark all entries of configuration table as "unmatched" 

Mark each entry which has at least one non-empty field as "non-empty" 

IF any addresses in address list 

THEN 

Perform SEND SETUP using all addresses in input list 

Send SDC 

Perform SEND DATA BYTES using the *AAD 

<PROGRAM MESSAGE> and 

the NL A END <PROGRAM MESSAGE TERMINATOR> 

Wait 100 ms minimum 

Set device-search to TRUE 

WHILE device-search is TRUE 

BEGIN 

Set current-field to manufacturer 
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Set data-byte to ISO 7-bit STX ('decimal value of 2*) 
Perform SEND DATA BYTES using data-byte 
Perform Acquire-Field 
IF field-detected is TRUE 

THEN 
BEGIN 

WHILE field-detected is TRUE 
BEGIN 
CASE current-field OF 
BEGIN 
manufacturer: set current-field to model number 
model number: set current-field to serial number 
serial number: set current-field to address 
address: set current-field to done 

OTHERWISE: set current-field to extra field 

END 
Perform Acquire-Field 
END 

IF current-field equals done 
THEN 

Perform Configure-Device 
ELSE 
BEGIN 
Generate error status indicating that the detected 
device has an improperly-formed identifier 
Perform Error-Exit 

END 
END 
ELSE 

Set device-search to FALSE 
END 
Send SDC 
END Set- Address 

17.7.5.2 Error Exit procedure 

BEGIN Error-Exit 

Send SDC 

Return error status and control to calling program 
END Error-Exit 
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17.7.5.3 Acquire Field procedure 
BEGIN Acquire-Field 

Set field-data-byte-pointer to beginning of current-field 

Perform Acquire-Byte 
IF byte-detected is TRUE 
THEN 

BEGIN 

Set field-detected to TRUE 
WHILE byte-detected is TRUE 

Perform Acquire-Byte 

END 

ELSE 

Set field-detected to FALSE 

END Acquire-Field 

17.7.5.4 Acquire Byte procedure 

BEGIN Acquire-Byte 

Set data-byte to decimal 1 27 
Perform SEND DATA BYTES using data-byte 
Wait 1 ms minimum, or until NRFD is FALSE 
IF SRQ is TRUE 

THEN 

BEGIN 

Set byte-detected to TRUE 
Set initial data-byte to decimal 64 
Set delta to decimal 32 
WHILE delta is 1 or greater 

BEGIN 
Perform SEND DATA BYTES using data-byte 
Wait 1 millisecond minimum, or until NRFD is FALSE 
IF SRQ is TRUE 
THEN 

data-byte » data-byte - delta 
ELSE 
data-byte - data-byte + delta 

IF data-byte is GREATER THAN decimal 126 or 
data-byte is LESS THAN decimal 32 

THEN 

BEGIN 

Generate error status indicating that an out-of-range 
byte has been found or some other device has 
interfered with the protocol by asserting SRQ. 
Perform Error-Exit 

END 

delta * delta / 2 
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END 

Perform SEND DATA BYTES using data-byte 

Wait 1 millisecond minimum, or until NRFD is FALSE 

IF SRQ is TRUE 

THEN 

Decrease value of data-byte by one 

Perform SEND DATA BYTES using data-byte + decimal 128 

Store data-byte in field indicated by current-field at 

position indicated by field-data-byte-pointer 
Increment field-data-byte-pointer 

END 

ELSE 

Set byte-detected to FALSE 

END Acquire-Byte 

17.7.5.5 Configure-Device procedure 
BEGIN Configure-Device 

Mark all unmatched non-empty entries as untested 

Set best-matched-entry to no-entry 

Set equal-score to zero 

FOR each non-empty AND untested entry 

BEGIN 

Set equal-fields to zero 
Set entry-match to TRUE 
Set test-field to TRUE 
WHILE test-field is TRUE 

BEGIN 

IF a non-empty entry field has not been tested, 
excluding the address field, in table order 

THEN 

IF the entry field is equal to OR is an initial 
substring of the corresponding acquired field, 
ignoring upper/lower case distinction and leading 
and trailing white space in either string 

THEN 

Increment equal-fields by one 
ELSE 

BEGIN 

Set entry-match to FALSE 
Set test-field to FALSE 

END 

ELSE 

Set test-field to FALSE 

END 

IF entry-match is TRUE 

THEN 
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IF equal-fields is GREATER THAN equal-score 

THEN 

BEGIN 

Set equal-score to equal-fields 

Set best-matched-entry to point to this entry 

END 

Mark entry as tested 

END 

IF best-matched-entry is no-entry 

THEN 

BEGIN 

Find first entry in table with manufacturer, model number, 
and serial number fields all empty 
IF empty entry does not exist 

THEN 

BEGIN 

Generate error status indicating configuration table 
overflow 

Perform Error-Exit 

END 

ELSE 

BEGIN 

selected-entry is empty entry 

Mark this entry as added and matched 

END 

END 

ELSE 

BEGIN 

selected-entry is best-matched-entry 
Mark selected entry as matched 

END 

Fill in manufacturer, model number, and serial number fields 
of selected entry with the corresponding acquired fields 
IF the address field of the selected entry is empty 

THEN 

BEGIN 

Store acquired listen address in selected entry address field 
Perform SEND DATA BYTES using acquired listen address 
as a data byte(s) 
END 
ELSE 

IF entry address field length does NOT EQUAL acquired 
address length. 

THEN 
Generate error indicating that the table address 
is incompatible with the device address. 
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Perform Error-Exit 

ELSE 

Perform SEND DATA BYTES using table entry address as 
a data byte(s) 

END Configure-Device 

1 7 . 7. 6 Additional requirements and guidelines 

The input configuration table supplied to the protocol controls the way in which addresses 
are assigned. If the user supplies an empty table, the protocol returns a table that 
duplicates the I EC 625?1 address configuration (within the address space specified in the 
input address list) prior to the execution of the protocol. That is, after the protocol has 
finished, the address configuration is unchanged. If all the table entry address fields are 
filled with addresses, exactly those addresses will be assigned. The addresses may be in 
any order. If more devices are detected than the input table can accommodate, then the 
controller shall indicate an error and leave the addresses of any additional devices 
unchanged. The protocol becomes more selective in assigning addresses as more fields 
are specified. For example, a manufacturer, model number, and address in a table entry 
will cause the protocol to assign that address to a device that has that manufacturer and 
model number. An entry with all fields specified will cause the protocol to assign the 
associated address to the one device that matches all the fields (excluding address), if 
the device exists. 



If several devices in the system have the same manufacturer and model numbers, and 
also have a serial number of ISO 7-bit character 0, the protocol can still detect the 
devices if each device has been previously set to a different address. 



A higher level protocol in the controller may interact with the Set Address protocol. It may 
determine whether to assign ascending addresses, addresses that duplicate some 
previous configuration or to leave the addresses unchanged. It also may check the Set 
Address protocol output table for address conflicts. Two or more address-configurable 
devices may be at the same address or an address-configurable device may share the 
same address with a non-address-configurable device. The higher level protocol must 
decide how to resolve the conflicts and reinvoke the Set Address protocol to change the 
address(es) as required. 



17.7.7 Standard compliance 

The SET ADD common controller protocol may optionally be supplied by controfiers. 

17.8 Test System protocol 
17.8.1 Keyword 
TESTSYS 
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17.8.2 Purpose 

To evaluate the readiness of a test system as can be determined from the results of the 
self-test query (see 10.38). 

1 7.8.3 Information requested by the protocol 

List of addresses representing the devices to be self-tested. 

17.8.4 Information supplied by the protocol 

A value of zero shall be returned if every device passes its self-test. Otherwise, a 
non-zero value shall be returned which indicates the number of devices that have failed 
followed by the addresses of those devices and their associated *TST? query responses. 

17.8.5 Controller algorithm 

BEGIN Self-Test System 

Initialize FAILED_DEVICES quantity to zero 

Execute SEND to all of the addresses, with *TST? as 

the <PROGRAM MESSAGE> and NL A END 

as the <PROGRAM MESSAGE TERMINATOR>. 
Send the IEC 625-1 Unlisten command (UNL) 
FOR each address in the input list 

BEGIN 

Execute RECEIVE control sequence 
IF the RECEIVE response is non-zero 

THEN 

BEGIN 

Put address and response into output table 
Increment FAILED.DEVICES quantity 

END 

END 

Place FAILED.DEVICES quantity into output table 

END Self-Test System 

1 7.8.6 Additional requirements and guidelines 
None 

1 7.8.7 Standard compliance 

The TESTSYS common controller protocol may optionally be supplied in a controller. 
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Annex A 

(informative) 



Compound headers usage and examples 



The use of compound headers is a relatively new concept. This annex presents some 
possible techniques a device designer may consider when implementing compound 
headers. Several possible levels of complexity and approaches for the device's parser are 
presented. Hypothetical command structures are illustrated to present some concepts 
device designers may find useful when designing a command structure. 



A.1 Compound header organization example using a tree 

Figure A-1 presents the command structure of a prototype device which has implemented 
compound headers using a tree structure. Headers were chosen with minimal mnemonic 
value to insure generality. 



(root) 



AA BB CC DO 



i i — i — i rnn i n 

EE FF GG HH EE II JJ KK II LL II JJ 



rh 



rH 



MM NN OO PP QQ 

RR SS 

Figure A-1 - Compound header organization example using a tree 

Some of the notable aspects of this organization: 

1) The paths through the tree are not all the same length. 
Z) The number of sub-nodes under a node is not constant. 
3) Node names are reused. 

Some legal program commands for this hypothetical device would be: 

:AA:EE 5 <PMT> 

:BB:EE 7 <PMT> 

:AA:HH ON <PMT> 

:CC:KK:MM 52 <PMT> 

NOTE • <PMT> is used to indicate a <PROGRAM MESSAGE TERMINATOR>. 
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A. 1 . 1 Use of the compound header rules 

The rules specified in 7.6.1.5 allow several implementations for the way a parser may 
behave if the leading colon on a <COMMAND PROGRAM HEADER> is omitted. 



The following command sequences illustrate the workings of the clause 7 rules for 
command-path generation. 

1) :AA:EE 5;:BB:EE 7 <PMT> 

The leading colon in the second <PROGRAM MESSAGE UNIT> puts the parser at 
the top of the command-tree. Both paths are legal. 

2) :AA:EE 5 <PMT> BB:EE 7 <PMT> 

The first <PROGRAM MESSAGE TERMINATOR> puts the parser at the top of the 
command tree. A leading colon at the beginning of the next <PROGRAM 
MESSAGE UNIT> is unnecessary since the first <PROGRAM MESSAGE UNIT> in 
a <PROGRAM MESSAGE> starts the parser at the root. 



3) :AA:EE7;FF5;GG8;HH 10<PMT> 

The entire path is not given in the second, third, and fourth <PROGRAM MESSAGE 
UNIT> elements. The rules specify that a ':AA:' is assumed to be prefixed to the 
following <PROGRAM MESSAGE UNIT> elements. This command is equivalent to: 

:AA:EE 7;:AA:FF 5;:AA:GG 8;:AA:HH 10<PMT> 

4) :CC:KK:MM 3;00 26;NN:SS 187 <PMT> 

The second and third <PROGRAM MESSAGE UNIT> elements are assumed to be 
prefixed by the implied prefix of the immediately previous command, ':CC:KK:'. This 
command is equivalent to: 

:CC:KK:MM 3;:CC:KK:00 26;:CC:KK:NN:SS 187 <PMT> 

5) :AA:EE 5;*ESR 32<PMT> 

The processing of common commands is unaffected by any previous compound 
commands. 

6) :AA:EE 7;*ESR 32;FF 5;GG 8;HH 10 <PMT> 

The insertion of the common command has no effect on the application of the 
prefixing rules. This command is equivalent to: 

:AA:EE 7;*ESR 32;:AA:FF 5;:AA:GG 8;:AA:HH 10<PMT> 

The following examples would cause an error with a parser that followed only the basic 
rules of clause 7. 

1) :AA:EE 7;BB:EE 7<PMT> 

The node 'BB' is not a sub-node of *AA'. This type of parser is unable to look at any 
nodes closer to the root than node 'AA'. 
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2) :CC:KK:MM 3;LL:PP 7 <PMT> 

The second <PROGRAM MESSAGE UNIT> would cause an error, since node 'LL' is 
not a sub-node of *KK\ The device attempts to execute the command 
:CC:KK:LL:PP 7, which is illegal. 

A.1 .2 Enhanced tree walking implementation 

A parser can be constructed which performs additional tree walking. The example 
presented here illustrates a parser that is able to "walk backwards up the tree". 

This type of parser would not generate errors on these command sequences: 

1) :CC:KK:MM 3;LL:PP 7 <PMT> 

The parser recognizes that node 'LL' is not a sub-node of node "KK\ The parser 
then looks at a level closer to the root to see if node 'LL' is a sub-node of node 
'KK's parent. 

This sequence would be interpreted the same as: 

:CC:KK:MM 3;:CC:LL:PP 7 <PMT> 

2) :AA:EE 7;BB:EE 7 <PMT> 

The parser is able to recognize that nodes 'AA' and 'BB' have the same parent 
node, the root. 

3) :CC:KK:MM 3;DD:II 7 <PMT> 

The parser recognizes that node "DD" is not a sub-node of nodes *KK' or "CC*. 
Searching continues towards the root and the parser recognizes that nodes 'CC 
and 'DD' have the same parent, the root. The parser is able to search towards the 
root until it finds a match or reaches the root of the tree. 

The sequence would be interpreted the same as: 
:CC:KK:MM 3;:DD:II 7 <PMT> 

The following examples would cause an error with both types of parsers: 

1) :AA:II7<PMT> 

Node 'II' is not a sub-node of 'AA'. A Command Error would be generated. 

2) :CC:KK:MM 3;EE 7 <PMT> 

Node *EE' is not a sub-node of node 'KK' nor node 'CC. Backward searching must 
stop at the root. A Command Error would be generated. 

3) :CC:KK:MM 3 <PMT> LL:PP 7 <PMT> 

When the parser recognizes the first <PROGRAM MESSAGE TERMINATOR>, it will 
start its next search from the top of the tree. Node 'LL' is not a sub-node of the root. 
A Command Error would be generated. 
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A.2 Compound header organization example using a graph 

Command structures other than trees are also possible using compound headers. Figure 
A-2 presents a "command-graph" of another prototype device with compound headers. 



(root) 



AA 



BB 



BB 



AA 



CC 

Figure A-2 - Compound header organization using a graph, example 1 

Some legal program commands for this device include: 

:AA:BB:CC 82<PMT> 
:BB:AA:CC 82<PMT> 

Another graph style structure is given in figure A-3. 

(root) 



r 

AA 

_L 



CC 



BB 



DD 

Figure A-3 - Compound header organization using a graph, example 2 

Some legal program commands for this device include: 

:AA:BB:DD 34<PMT> 
:CC:DD 34<PMT> 

The device designer has the freedom to deal with complicated command structures using 
a great deal of creativity. The device designer should be aware that the semantics of such 
constructs may not be obvious to the user. 
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Annex B 

(informative) 



Device/controller synchronization techniques 



This annex presents a series of examples which illustrate the intended use of the various 
synchronization capabilities presented in clause 12. 

This annex contains no new device requirements. It presents examples and techniques 
that can be used in application software to assure correct synchronization of the 
controller with the device. These examples will assist the device designer in 
understanding the functional capability provided by the device requirements presented in 
clause 12. 

B.1 Simple device and application program synchronization 

The IEC 625-2 status reporting capability provides a simple means to synchronize the 
operation of a device with an application program. The synchronization is achieved by 
using one of the status reporting facilities to determine when the required device 
operation is complete. 

For example: The application program sends a query command to the device. The 
query command used will be one which does not allow the device to return data until a 
desired operation is complete. The application program sends the query command 
when it must wait for the device to respond. When the device is ready, it places the 
output message in the Output Queue and sets the Message Available summary bit in 
the status byte. When the controller reads the response from the query command, the 
application program can continue knowing that the device has completed the desired 
operation. 

Synchronization can also be achieved by using the "Operation Complete" message in the 
Standard Event Status Register or by using the *WAI common command. 

The following examples illustrate the use of each of the following synchronization tools. 



• The *OPC? Common Query Command 

• The *OPC Common Command 

• The *WAI Common Command 

• The MAV message in the Status Byte Register 

B.2 Types of devices 

For the purposes of the examples in this annex, devices will be of two types, 
stimulus-devices and/or response-devices as defined in 12.8.3.1 and 12.8.3.2. 

B.2.1 Hypothetical stimulus-device 

For the purposes of the examples in this section, we will use a Signal Generator 
(SIGGEN) as a hypothetical stimulus-device. We will assume that the IEC 625-1 address 
of the device is represented by the decimal number 19. 
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The device is assumed to meet all the requirements of this standard. The following list of 
device-specific commands are assumed to exist in the device: 

SETUP This <PROGRAM MESSAGE UNIT> is assumed to do all the setup 

programming that the application programmer needs. In a real device 
the setup might be a string of device-defined commands. 

FREQ <NRf> This <PROGRAM MESSAGE UNIT> causes the SIGGEN to generate 
the output frequency that is specified in the NRf numeric format. 

FREQ:INC This <PROGRAM MESSAGE UNIT> causes the SIGGEN to increment 
its output frequency by a fixed amount. 

NOTE - The device-specific headers used by this hypothetical device have been selected to make the 
following examples understandable. They are not intended to set a precedent for real devices. 



B.2.2 Hypothetical response-device 

For the purposes of the following examples, we will use a Digital Volt Meter (DVM) as a 
hypothetical response-device. We will assume that the IEC 625-1 address of the device is 
represented by the decimal number 8. 

The device is assumed to meet all the requirements of this standard. The following list of 
device-specific commands are assumed to exist in the device: 

SETUP This <PROGRAM MESSAGE UNIT> is assumed to do all the setup 

programming that the application programmer needs. In a real device 
the setup might be a string of device-defined commands. SETUP is a 
Sequential Command. 

MEAS This <PROGRAM MESSAGE UNIT> causes the DVM to initiate the 

measurement. 

MEAS? This <PROGRAM MESSAGE UNIT> causes the DVM to initiate the 

measurement and return a <RESPONSE MESSAGE> upon completion 
of the measurement operation. 

LAST? This <PROGRAM MESSAGE UNIT> causes the DVM to return the 

results of the last measurement without triggering a new one. The 
measurement will be returned as a single <RESPONSE MESSAGE>. 

MEAS:CONT? This <PROGRAM MESSAGE UNIT> causes the DVM to take a 
measurement and return its results as a <RESPONSE MESSAGE 
UNIT>. After the controller reads the measurement result, the DVM 
takes another measurement and provides its results in the same 
manner. The process continues as long as the controller will accept 
the data. The <RESPONSE MESSAGE UNIT> elements are separated 
by <RESPONSE DATA SEPARATOR> elements, a comma. The 
<RESPONSE MESSAGE TERMlNATOR> is not sent. 

TRIG.EXT This <PROGRAM MESSAGE UNIT> configures the device such that it 
will not perform a measurement until an External Control Signal is 
stimulated. When the signal is stimulated the DVM will take a 
measurement. 
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This is an optional common command, it is used to determine the 
function of Group Execute Trigger. It is defined in 10.4. 



NOTE - The device-specific headers used by this hypothetical device have been selected to make the 
following examples understandable. They are not intended to set a precedent for real device*. 



B . 2 . 3 Hypothetical controller language 



For the purposes of the examples in this annex we will use a hypothetical controller which 
has the following language. The keywords from clauses 16 and 17 have been used. 



RESET a 



SEND a; * " 



RECEIVE a; num 



An Interface Clear (IFC) is performed. A Device Clear 
(DCL) is sent. The *RST common command is sent to 
the device whose IEC 625-1 address is represented by 
the number "a". 

The number "a" will be used as the IEC 625-1 address. 
Data enclosed in the quotes will be sent to the device. 
The sent message will be automatically terminated using 
NL A END. 

The number "a" will be used as the IEC 625-1 address. A 
<RESPONSE MESSAGE UNIT> is read from the device. 
The numeric results are placed in the variable "num". 



TRIGGER a1,a2 an 



READ STATUS BYTE a; Sts 



WAIT SRQ 



A Group Execute Trigger command (GET) will be sent to 
all devices whose IEC 625-1 address is in the list of 
numbers "a1" through "an". 

The number "a" will be used as the IEC 625-1 address. 
The IEC 625-2 status byte is read from the device using 
a serial poll. The numeric result is placed in the variable 
"sts". 

The controller waits for a SRQ on the IEC 625-1 bus. 
During the waiting time the Application Programmer can 
use the controller to do other useful work. The details of 
how the controller proceeds doing useful work while at 
the same time waiting for an SRQ will not be shown. 



REPEAT 
BEGIN 
END 



Statement between BEGIN and END will be repeated 
indefinitely 



IF (descriptive expression) 
THEN 
ELSE 



If the descriptive expression is TRUE, statements after 
THEN will be processed. IF FALSE statements after ELSE 
will be processed. BEGIN and END may be used to 
group statements after a "THEN" or an "ELSE". 
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B.3 Synchronization with stimulus-devices 

Stimulus-devices generally require device-defined setup commands to specify the desired 
output signal. The application program must then determine that the stimulus is valid 
before it allows another component in the system to utilize the signal. This synchronization 
can be done with the *OPC? query command. The "Operation Complete" query permits a 
device to indicate when it has completed an operation that was initiated by a <PROQRAM 
MESSAGE UNIT>. 



A stimulus-device will indicate that it has completed a stimulus operation only when its 
outputs are valid. 

EXAMPLE: A stimulus-device is sent a programming message to change its output followed by an *OPC? 
query command. The "Operation Complete" message is placed in the Output Queue when the device has 
recognized the *OPC? query command and has also provided the output signal specified by the previous 
programming message. 

B.3.1 Stimulus-device synchronization using a <RESPONSE MESSAGE> 

The following example illustrates the simplest method for synchronizing a stimulus-device 
with an application program. In this example the application program uses device-specific 
commands to specify the desired stimulus. The *OPC? query command is used to provide 
a <RESPONSE MESSAGE> when the output signal is valid. 



The principles of this example apply equally well to device functions which do not provide 
a stimulus but do take time and do not return a <RESPONSE MESSAGE>. Note that in the 
following example, the controller will not be able to complete the read operation In STEP 
5 until the device's output has changed to the new frequency. This will cause the 
IEC 625-1 bus to be held off while the controller is waiting for the device. The read 
operation is used for synchronization only: the numeric value read is ignored. 



Stimulus example application program using a 
<RESPONSE MESSAGE> 

STEP 

1. RESET 19 Send IFC, DCL, *RST. 

2. SEND 19; "*SRE 0" Turn off all Service Requests. 

3. SEND 19; "SETUP" 

4. SEND 19; "FREQ 10.0E3; *OPC?" Set Frequency to 10 KHz. 

5. RECEIVE 19; num The number returned and stored in 

variable "num" is an ISO 7-bit character 
"1". discard it. 

. . . proceed with application, knowing that the device's 
. . . new output is valid 
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B.3.2 Stimulus-device synchronization with Service Request 



The following example illustrates how a stimulus-device can be synchronized with an 
application program by using SRQ. In this example the device is programmed to generate 
a new output signal and generate a service request when the new stimulus signal is valid. 
Upon receiving the service request, the controller programs other elements in the system 
to make use of the stimulus signal. 

The device designer will insure that the SRQ will not be generated until the desired output 
signal is valid. 

The controller can perform other useful work while the device is changing its output. 



The application program sends the device-specific stimulus command "FREQ" followed by 
the *OPC? common query command. The device sets the Message Available summary bit 
in the status byte when the stimulus is valid. Note that proper use of the Message 
Available Summary bit in the status byte eliminates the need for application program time 
delays. 

Stimulus synchronization with Service Request 

STEP 

1. RESET 19 Send IFC, DCL, *RST. 

2. SEND 19; "SETUP" 

3. SEND 19; "*SRE 16" Enable MAV Service Request. 

4. SEND 19; "FREQ 10E3; *OPC?" Set Frequency to 10 kHz. 

5. WAIT_SRQ While waiting for Service Request 

controller can do other useful work. 



6. 
7. 


READ STATUS BYTE 19; sts 
JF (MAV message is NOT in sts) 














THEN 


unexpected SRQ! 










BEGIN 














. . process unexpected SRQ 














GO TO 5 














END 












8. 


RECEIVE 19; num 


num is an 
discard it. 


ISO 


7-bit 


character 


"1 



. direct the system to do something useful 
. with the stimulus signal. 
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B.3.3 Stimulus-device synchronization without <PROGRAM MESSAGE> 
elements 

The following is an example of how a stimulus-device can be operated without requiring 
<PROGRAM MESSAGE> elements after the initial setup. 

Assume that the device is the hypothetical Signal Generator defined above. Assume also 
that it can have its output frequency incremented by use of the IEC 625-1 Group Execute 
Trigger message (GET). 

In this example the output frequency of the SIGGEN is incremented each time a GET is 
received. The Message Available bit (MAV) in the Status Byte is read via a serial poll so 
that the controller will know when the new frequency is valid. 



Each time a GET is sent to the SIGGEN, it is the same as sending the <PROGRAM 
MESSAGE> "FREQrINC; OPC?". The new program message empties the Output Queue, 
which causes MAV to go FALSE. When the operation is complete, the *OPC? response, 
an ISO 7-bit character "1", will be placed into the Output Queue. Since the Output Queue 
is not empty, MAV becomes TRUE, which in turn causes the device to make SRQ TRUE. 



The new <PROGRAM MESSAGE> also causes the device to report a query error as the 
unread contents of the Output Queue are discarded when a new <PROGRAM MESSAGE> 
is received. This error is ignored as the ESB bit is not enabled by the "*SRE 16" 
command. 



Stimulus-device synchronization without 
<PROGRAM MESS AG E> elements 



STEP 
1 

2 



RESET 19 
SEND-SRE16" 



Send IFC, DCL, *RST. 

Enable (MAV) Service Request. 



3 SEND 19; "SETUP; FREQ 1 000' 



Initialize Frequency. Assume that 
SETUP includes setting the 
increment size that will be used 
each time a GET is received. 



4 SEND 19; "*DDT #0 FREQ:INC; *OPC?' 



5 REPEAT 

6 BEGIN 

7 TRIGGER 19 



Causes device to respond as 
though "FREQ:INC; OPC? NL*END" 
had been received each time a GET 
is received. 

Device is now ready to Accept GET 
messages. 



Controller sends GET here. The 
SRQ will not occur until after the 
GET is received and the SIGGEN 
has settled at the next frequency. • 
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8 WAIT_SRQ While waiting for Service Request, 

controller can do other useful work. 

9 READ STATUS BYTE 19; sts 

10 IF (MAV message is NOT in sts) 

11 THEN unexpected SRQ from another 

IEC 625-1 device. 

12 BEGIN 

. . . process unexpected SRQI 

13 GO TO 7 

14 END 

. . . direct the system to do something useful 
. . . with the stimulus signal. 

15 END 

The application performs the following in a loop: 

STEP 

1 controller sends GET to Signal Generator 

2 wait for Service Request 

3 perform a serial poll on the device 

Since the GET message does the equivalent of a <PROGRAM MESSAGE> after a prior 
query command was terminated, the Output Queue is discarded and consequently the 
MAV message goes FALSE. Discarding the Output Queue causes a Query Error. 

B.4 Synchronization with Response-devices 

Response-devices generally require device-defined setup commands and a query 
command followed by the controller reading the resultant measurement. The following 
examples illustrate this method. 

B .4 . 1 Simple Response-de vice synchronization 

The following example illustrates the simplest method for synchronizing a response-device 
with an application program. In this example the application program requests a 
measurement and then waits at step 7 for the results. The sequence is repeated 
indefinitely. The read measurements are always valid because the device does not send 
data until it has completed each measurement. 
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Response-device synchronization using a <RESPONSE MESSAGE> 



STEP 




1. 


RESET 8 Send IFC, DCL, *RST. 


2. 


SEND 8; "*SRE 0" Turn off all Service Requests 


3. 


SEND 8; "SETUP" 


4. 


REPEAT 


5. 


BEGIN 


6. 


SEND 8; "MEAS?" 


7. 


RECEIVE 8; num 


8. 


. . do something useful with the number. . 


9. 


END 



B.4.2 Response-device synchronization with Service Request 

The following example illustrates the Service Request method for synchronizing a 
response-device with an application program. In this example the controller requests a 
measurement and then waits for a service request to be generated. Upon receiving the 
service request, the controller reads the results. The sequence is repeated indefinitely. 
The read measurements are always valid because the device does not issue the service 
request until it has completed each measurement. The controller can be used to perform 
other useful work while the device is performing the measurement. 

The application program sends the device a device-specific query to retrieve the 
measurement data. The device sets the Message Available summary bit in the status byte 
when the measurement data is available. The Message Available Summary bit in the 
status byte eliminates the need for application program time delays. 



Response-device synchronization with service request 

STEP 

1. RESET 8 Send IFC. DCL, *RST. 

2. SEND 8; "*SRE 16" Enable (MAV) Service Request. 

3. SEND 8; "SETUP" 

4. REPEAT 

5. BEGIN 

6. SEND 8; "MEAS?" 

7. WAIT_SRQ while waiting controller can do other useful 

work. 

. . . program continues when SRQ is received 

8. READ STATUS BYTE 8; sts 

9. IF (MAV message is NOT in sts) 

10. THEN unexpected SRQ! 

11. BEGIN 
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. . . check other devices and 
. . . process unexpected SRQ 

12. GO TO 7 

13. END 

14. RECEIVE 8; num 

. . do something useful with the number. 

15. END 



B.4.3 Response-device synchronization without <PROGRAM MESSAGE> 
elements 

The following example illustrates how. a response-device can be made to take a series of 
measurements without <PROGRAM MESS AG E> elements being used within the loop. The 
application allows for quick, low overhead, reading of measurement results, in this 
example the controller requests the device to return measurement results as a 
continuous stream of <RESPONSE DATA> elements. Read measurements are always 
valid because the device does not send data until it has completed each measurement. 
We assume that the controller returns comma "," delimited measurement values, one by 
one, to the application program. 



Response-device synchronization without <PROGRAM MES$AGE> 

elements 

STEP 

1. RESET 8 Send IFC. DCL, *RST. 

2. SEND 8; "*SRE 0" Turn off all Service Requests. 

3. SEND 8; "SETUP; MEAS:CONT?" 

4. REPEAT 

5. BEGIN 

6. RECEIVE 8; num (delimited by ",") 

7. ... do something useful with the number. . 

8. END 

B.4.4 Device communications while waiting for a measurement 

The following example illustrates how a response-device can be programmed to take a 
measurement and then while the device is performing it, allow the device to send and 
receive messages. This capability can be useful when a measurement is very time 
consuming and there is some useful information that the controller may wish to read from 
the device while the measurement is in process. The example uses the *OPC common 
command to generate the Operation Complete message in the Standard Event Status 
Register when the measurement completes. This example also uses a service request to 
eliminate the need to poll the Standard Event Status Register with the "*ESR?" common 
query command. 
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Device communications while waiting for a measurement 

STEP 

1. RESET 8 Send IFC, DCL, *RST. 

2. SEND 8; "SETUP" 

3. SEND 8; "*SRE 32; *ESE 1" Enable (ESB) Service Request. Allow 

OPC bit to set ESB message. 

4. SEND 8; "MEAS; *OPC" Begin a measurement. 

5. WAIT_SRQ 

. Perform other tasks involving the device by 

. sending <PROGRAM MESSAGE> elements or reading 

. <RESPONSE MESSAGE> elements. Avoid any of the 

. following: *CLS, *RST, *SRE, *ESE 

. or any device-specific command 

. that has a pending operation. 

6. READ STATUS BYTE 8; sts 

7. IF (RQS message is TRUE in sts) 

THEN 
BEGIN 

SEND 8; "LAST?" 
RECEIVE 8; num 

. . do something useful with the number . . 
END 
ELSE GO TO "Unexpected Service Request Handling" 

NOTE - The Standard Event Status Register does not have to be read to determine that the Operation 
Complete message is TRUE because this is the only message that has been enabled to generate an SRQ. A 
*CLS or a query of the Standard Event Status Register is required to remove the SRQ if the procedure is to 
be repeated. 

B.4.5 Synchronization using an external control signal 

The synchronization of a response-device with an application program can be 
accomplished by use of an external-control-signal. This method may be necessary when 
an asynchronous event must determine when a measurement is taken. This synchronization 
can be accomplished using any of the three methods indicated in the previous examples. 
The only changes required are to add device-specific setup commands which direct the 
device to take measurements only when the external-control-signal is received. (See the 
TRG:EXT" command for the hypothetical DVM.) 



The measurements read are always valid because the device does not send data until it 
has completed each measurement. 
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B.4.6 Example involving simultaneous trigger of two response-devices 



The following example shows how two response-devices can be commanded to take a 
measurement at the same time. The IEC 625-1 Group Execute Trigger (GET) command is 
used to start the measurement. Both devices are assumed to be the hypothetical Digital 
Volt Meter (DVM) defined above. The two devices have IEC 625-1 addresses of 8 and 9. 
The application requires that a pair of voltages be .sampled at the same time. 



This example uses the *OPC? query command to verify that each device has emptied its 
Input Buffer and has executed ail prior commands. Since the device's Input Buffer is 
known to be empty, the application program also knows that the device is in a state where 
it can immediately execute the Group Execute Trigger (GET) command. Since the two 
devices are the same make and model, this example assumes that the two measurements 
will be taken close together in time. 



If the timing needs to be controlled any closer than can be achieved with a Group Execute 
Trigger, then the application program will have to use means outside of IEC 625-1 to 
accomplish the parallel trigger. This triggering could be done using special external trigger 
hardware in the devices. 



Simultaneous trigger of two response-devices 



STEP 

1. 

2. 
3. 



RESET 8 
RESET 9 
SEND 8; "*SRE 0; SETUP" 



4. SEND 9; "*SRE 0; SETUP" 

5. SEND 8; "*DDT #0 MEAS?" 

6. SEND 9; "*DDT #0 MEAS?" 

7. SEND8;*OPC? 

8. RECEIVE 8; num 



Initialize (DVM-1). 

Initialize (DVM-2). 

Turn off Service Requests Setup 
(DVM-1). 

Turn off Service Requests Setup 
(DVM-2). 

Set DVM-1 to perform a measurement 
upon receipt of a Group Execute 
Trigger. 

Set DVM-2 to perform a measurement 
upon receipt of a Group Execute 
Trigger. 

The number returned and stored in 
variable num is an ISO 7-bit "1", 
discard it. DVM-1 's parser is idle. 



9. SEND 9; "*OPC?" 
10. RECEIVE 9; num 



The number returned and stored in 
variable num is an ISO 7-bit "1", 
discard it. DVM-2's parser is idle. 



At this point the Application program directs other 
components in the system to provide the signals 
that are to be measured. 
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11. TRIGGER 8,9; 



This command addresses DVM-1 and 
DVM-2 to listen and then sends the 
Group Execute Trigger Message. 



12. RECEIVE 8; num-1 



13. RECEIVE 9; num-2 



When the measurement from DVM-1 
completes, it is sent to the controller 
and placed in variable num-1 . 

When the measurement from DVM-2 
completes, it is sent to the controller 
and placed in variable num-2. 



do something useful with the read 
measurement data in num-1 and num-2. 



NOTES 

1 Even though the measurements were read by the controller at different times, they were completed at 
the same time. 

2 The *DDT commands would be unnecessary if the device had implemented the "DT1" subset and simply 
defined Group Execute Trigger to cause the device to take a measurement. If the device has been built this 
way the above example might be changed in the following manner. 

The application program would have placed the DVMs in a deferred trigger mode as part of the setup. This 
mode would keep the DVM from taking a measurement until triggered by a GET. The OVM "MEAS?" query 
commands would not need to be sent to each DVM at all. The GET would be sent to both device* causing 
parallel measurements. The resultant data would then be read from each DVM. 

B.5 Generalized synchronization independent of queries 

Synchronization with device operation can also be done with the *OPC command. This 
command is identical to the *OPC? query command except that the OPC bit is set in the 
Standard Event Status Register instead of generating the ISO 7-bit "1" as an output 
message. The *OPC command can be used to synchronize either stimulus-devices or 
response-devices. The *OPC bit of the event status register can be monitored to 
determine that all pending operations have been completed. 



Assume a hypothetical device which can perform three overlapped operations: OP1, OP2, 
and OP3. Each of these commands are Overlapped Commands as defined in 12.2. 



Synchronization independent of queries 

STEP 

1. RESET 19 Send IFC, DCL, *RST. 

2. SEND 19; "SETUP" 

3. SEND19;"*SRE32;*ESE1;*CLS" Enable (ESB) Service Request. Allow 

OPC bit to set ESB message. CLEAR 
Standard Event Status Register. 

4. SEND 19; "OP1 ; OP2; OP3; *OPC" Begin a measurement. 

5. WAIT SRQ 



270 



IS10767(Part2):2001 
IEC 60625-2 (1993) 



6. 
7. 



. Perform other tasks involving the device by 

. sending <PROGRAM MESSAGE> elements or reading 

, <RESPONSE MESSAGE> elements. Avoid any of the 

. following: *CLS, *RST, *SRE, *ESE 

. or any Overlapped Command. 

READ STATUS BYTE 19; Sts 

IF (RQS message is TRUE in sts) 

THEN 



BEGIN 



Device has completed all three 
commands: OP1, OP2, and OP3. 

Proceed with application. 



END 

ELSE GO TO "Unexpected Service Request Handling" 

NOTE - The Standard Event Status Register does not have to be read to determine that the Operation 
Complete Message is TRUE because this is the only message that has been enabled to generate an SRQ. 
However, before the program could be written as a loop, the Standard Event Status Register would have to 
be cleared each time. Clearing can be done by sending a *CLS command or by reading the Standard Event 
Status Register by using the *ESR? query command. 

B.6 Device synchronization using the *WAI command 

The following example illustrates the simplest method for insuring that device operations 
are performed in order. 

In this example the application program uses device-specific commands to start an 
operation in a response-device. The *WAI command is used to force the device to 
complete this operation before allowing the device to perform a measurement. 



The device will be commanded to initiate an internal calibration operation with the 
following command: 

"CALIBRATE' 

For the purposes of this example assume that the "CALIBRATE" command is an 
Overlapped Command and starts an operation as defined in 12.2. By using the *WAI 
command directly after "CALIBRATE" this Overlapped command operates as though it was 
a Sequential Command. The application program then commands the device to perform a 
measurement. Since the *WAI command was used, the application program knows that the 
measurement was performed after the calibration operation had been completed. 
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STEP 
1. 
2. 
3. 
4. 



Device synchronization using the *WAI command 



RESET 8 

SEND8;"*SRE0" 

SEND 8; "SETUP" 

SEND 8; "CALIBRATE; *WAP 



5. SEND 8; "MEAS?" 



Send IFC, DCL, *RST. 

Turn off all Service Requests. 



Start Calibration, the *WAI command 
forces the device to complete the 
calibration operation before the 
<PROGRAM MESSAGE UNIT> in 
Step 5 is executed. 

The device is commanded to take a 
measurement and return its results as 
a <RESPONSE MESSAGE>. 



RECEIVE 8; num 



The number returned and stored in 
variable num is the valid measurement 
results. 



NOTE - If the *WAf command had not been used, steps 5 and 6 would have been completed before the 
calibration operation had finished. Therefore, the measurement would not have been performed at the correct 
time. 

B.7 System example involving both a Response- and Stimulus-device 

The following example involves a system with four components: 

• An I EC 625-2 Stimulus-device (Hypothetical SIGGEN) 

• An I EC 625-2 Response-device (Hypothetical DVM) 

• An I EC 625-2 System Controller (Hypothetical language) 

• A two-port Device Under Test (DUT) 

The system topology is illustrated in figure B-1. 



SIGGEN 



CONTROLLER 



DUT 



DVM 

T 



system bus 



Figure B-1 - System topology for Response- and Stimulus-device example 

The application calls for a series of measurements to be made where the SIGGEN 
stimulates the DUT with one thousand different frequencies. The DVM measures the DUT 
response at each frequency and sends the data to the controller. 

The IEC 625-1 address for the SIGGEN is 19. The address for the DVM is 8. 

The following example is very simple and does not use any Service Requests. 
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System example involving both a Response- and Stimulus-device 



STEP 



1. RESET 8 

2. RESET 19 

3. SEND 8;"* SRE 0; SETUP" 

4. SEND 19; "SRE0; SETUP" 

5. SEND 19; "FREQ 1000; *OPC? B 

6. REPEAT 1000 TIMES 

7. BEGIN 

8. RECEIVE 19; num 

9. WAIT for DUT response time 

10. SEND 8; "MEAS?" 

11. RECEIVE 8; num 

... do something useful with the read 
. . . measurement data 



Send IFC, DCL and *RST to initialize 
(DVM). 

Send IFC. DCL and *RST to initialize 
(SIGGEN). 

Turn off Service Requests Setup 
(DVM). 

Turn off Service Requests Setup (SIG- 
GEN). 

Set SIGGEN Start Frequency. 



Response is ISO 7-bit "1", ignore. 



Command (DVM) to measure. 

Read from (DVM). 

/ 



12. SEND 19; "FREQ:INC; *OPC?" Increment SIGGEN Frequency. 

13. END 

NOTE - The WAIT statement in STEP 9 is to allow time for the DUT to respond to the stimulus signal that 
was applied. It is not necessary to allow for timing in the SIGGEN or DVM. Their timing requirements are 
taken care of by correct implementation of the synchronization features of this standard. 
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Annex C 

(informative) 



Automatic system configuration example 



The following example illustrates the interaction of the SETADD protocol and the *AAD 
common command in detecting three address-configurable devices on an IEC 625-1 bus. 
The identifiers for the three devices are shown in table C-1 along with the addresses that 
will be assigned. Each identifier consists of the four fields shown. 



The protocol searches out each character (a data byte on the IEC 625-1 bus) of each 
identifier from left to right (manufacturer to current listen address) and will conduct the 
search for as many times as there are unique identifiers. 

Table C-1 - Device identifiers/assigned addresses 
— Identifiers ^. 



Device 


Manufacturer 


Model « 


Serial # 


Current 
address 


Assigned 
address 


#1 


N 


B 


4 


1(1) 


«(1) 


#2 


N 


BB 


3 


$(4) 


%(5) 


#3 


M 


A 


6 


!(D 


#0) 



C.1 Overall flow of the protocol 

The devices are detected in the order shown in figure C-1. Each identifier search is 
initiated with the STX character (decimal value of 2). 



Identifier 


Search # 1 




Search # 2 


Search # 3 


Search 
Initiation 




Device # 1 




Device # 1 
































STX 






Device #2 - 


~ 


STX 


JL- 


Device # 2 


HSTX 




Device # 1 




STX 






























DONE 






Device #3 - 






Device # 3 
detected 


Device # 2 Device # 1 No devices 
detected detected detected 



Figure C-1 - Overall protocol flow 

Device #3 is detected first because the protocol chooses the identifier which has the 
lowest-valued character in the position it is testing. In this example, the "^" appears first 
as the lowest-valued character. Its decimal value is 77 whereas "N" has a value of 78. 
Device #2 is detected next because the protocol chooses a superset of a field over that 
field itself. That is, the superset field "BB" is chosen over "B". Finally, only Device #1 is 
left and is guaranteed to be detected since it has exclusive control in guiding the 
controller to its identifier characters. 
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C.2 Description of the identifier searches 



The three searches are described in more detail in figure C-2 below. The participation 
profile of each device is given along with the identifier characters that have been 
determined by the controller. <eof> indicates that an end-of-field condition has occurred. 
A succession of two <eof>'s is a signal that the entire identifier has been searched and a 
device has been detected (only one still participating). 
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#3 detected) 
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4 
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8 
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search # 




















Devices 


1 
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2 
















"# H (3) 




3 


3 


3 


3 


3 


3 3 


3 


3 


address 
assigned 






e 




e 




e 


e 


e 




Characters 


M 





A 





6 


o I 








---» 


determined 




f 




f 




f 


f 


f 














SEARCH #2 
















(Device #2 detected) 







Character 12 3 4 5 6 7 
search # 

Devices 1 1 1 

participating 2 2 2 2 2 2 2 

e e e 

Characters N o B B o 3 o 

determined f f f 



8 9 10 



2 2 2 
e e 

$00 

f f 



Character 1 2 
search # 

Devices 
participating 1 1 



SEARCH #3 
(Device #1 detected) 

4 5 6 7 8 



1111111 



"%" (5) 

address 

assigned 



e e e e e 

Characters NoBo4oloo 
determined f f f f f 



T(1) 

address 

assigned 



--■$> 



Figure C-2 - Identifier searches 

C.3 Description of the character search 

Each character search is made up of a character search initiation character and a 
character search body (figure C-3). 
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C.3.1 The search initiation character 

A participating device is required to assert SRQ TRUE if the controller places a data byte 
on the bus whose value is greater than the identifier character it is using for comparison. 
Otherwise, the device is required to assert the SRQ line passive FALSE. Since the 
maximum value an identifier character can have is decimal 126, the character search 
initiation character, decimal 127, will cause any device desiring a character to be 
searched to assert SRQ TRUE. This action will cause the controller to execute the search 
body. 



Character 

Search 

Initiation 

Character 

(decimal 127 

byte) 



Character 
Search 
Body 

(data bytes 
from 32 to 
126) 



Figure C-3 - Character search elements 



C . 3 . 2 The search body 



The search body consists of a seven-step successive-approximation binary search that 
starts with a data byte having a decimal value of 64 (the "<§>" character) and a delta of 
value 32. If the data byte causes an SRQ indication, the controller subtracts the delta 
from the data byte to form the next data byte. Otherwise, it adds the delta. Then it halves 
the delta. This process continues until the data byte calculated with the delta of 1 is sent. 
From the resulting SRQ indication, the controller can determine the lowest-valued 
character active in the search. If the SRQ line is FALSE, the character is equal to the last 
data byte sent. If it is TRUE, the character is one less than the last data byte sent. At this 
point the controller sends the character it has determined with the DI08 line asserted 
TRUE. (Previously, DI08 was FALSE.) This line asserted TRUE indicates to each 
participating device that if its character equals the data byte (excluding the DI08 value), 
then the device is to continue participating. Otherwise, the device is to cease 
participating until the next STX character signals the beginning of a new identifier search. 
A graphical representation of this process is shown in figure C-4. 



C.4 Detailed description of the search process 

C.4.1 Manufacturer search for the three sample identifiers 

Figure C-5 illustrates the searching sequence for detecting the "M" character of Device #3. 
The SRQ lines of the active devices interact to guide the controller to the lowest-valued 
character being presented. 

The lowest-valued character "M" (value 77) caused no SRQ TRUE indication with the delta 
of 1. Thus it was sent again with DI08 TRUE. This action caused devices #1 and #2 to 
cease participating in the protocol since their characters did not equal "M". 
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Immediately after the "M M is detected, the figure shows that an end-of-fietd (<eof>) was 
detected. That is, Device #3 did not assert SRQ TRUE upon receiving the next character 
search initiation character (decimal 127) in step 10. Had Device #3 been at the end of its 
last field, it would again indicate an <eof> condition upon receiving the character search 
initiation character to indicate a zero length field. The controller is then aware that a 
device has been detected. 



C.4.2 Detection of a superset field 

Figure C-6 illustrates the manner in which the protocol selects the superfield. The first "B" 
is detected in steps 1-9. Then the controller sends the next search initiation character in 
step 10. Device #1 responds by asserting SRQ passive FALSE as an indication that <eof> 
has been reached. Device #1 then expects the controller to send another search initiation 
character to start the search of its serial number field. However, the controller detected 
an active TRUE SRQ assertion from Device #2 and starts the search body with a decimal 
64 data byte. As a result of not seeing the second decimal 127 data byte, Device #1 
ceases participating. 



SRQ = FALSE 



SRQ - FALSE 



112 



-/.. 



SRQ - TRUE 



SRQ - FALSE 



SRQ = FALSE 



SRQ - TRUE 



SRQ » TRUE 



FALSE 
DIQ8 Line 



TRUE 



NOTES 

1 Each box represents a data byte sent by the controller and its decimal value is shown within. 

2 "X" equals the data byte calculated with delta equal to one. Thus. X or X-1 represents the lowest-valued 
character, depending upon the SRQ line state following transmission of *X". 

Figure C-4 - Search body 
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Figure C-5 - Character search action for a manufacturer character and 
an end-of-field <eof> 
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Figure C-6 - Detection of the superset field BB 
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